事情是这样的

痛点：迁移后上线。报表数据少了十几条，业务方直接发现异常，导致紧急回滚和额外的排查成本。老实说，

去年给一个客户做迁移。数据库从 MySQL 换到金仓。代码比如改完，还有数据导完，再有测试环境跑了一遍，都正常。上线那天业务方看了一眼报表，说数据不对，少了十几条。其实，

我赶紧查 SQL。发现是这么写的：

SELECT *
FROM t1
LEFT JOIN t2 ON t1.id1 = t2.id2
WHERE t2.name2 = 'cc';老实说，

业务方说这个报表要统计所有使用者。那些没下过单的使用者也要显示“暂无订单”。左表是使用者表，右表是订单表。用 LEFT JOIN，没订单的使用者应该保留，订单相关的字段显示为空。

结果那十几条“没下过单”的使用者，全没了。

查了半天问题出在调整器身上

痛点：调整器自动把外连接改为内连接。导致业务语义被破坏，却没有任何提示，让开发者误以为查询本身正确。

我把这条 SQL 拿到数据库里单独跑了一遍，又把执行计划拉出来看。发现执行计划里压根没有 LEFT JOIN，变成了普通的 Hash Join。

调整器把 LEFT JOIN 自动转成了 INNER JOIN。

我当时第一反应是：它凭什么替我做这个决定？

后来理了一遍 SQL 的执行顺序，才发现问题在 WHERE 条件上。不过，

正常的执行顺序是：先做 JOIN。生成中间结果，再用 WHERE 过滤。对 LEFT JOIN 右表没匹配上的行，右表字段会是 NULL。不过，接下来 WHERE 条件一过滤。t2.name2 = 'cc'NULL 等于 'cc' 是 false，所以这些行就被扔掉了。

调整器一看，反正你 LEFT JOIN 产生的 NULL 行最终都会被 WHERE 干掉。那我直接帮你换成 INNER JOIN 算了效率更高。

逻辑上说得通，但业务语义变了。

那些没匹配上的行，在 LEFT JOIN 阶段本来应该保留。但因为 WHERE 条件里有右表字段的过滤，它们在结果里消失了。等于说 LEFT JOIN 白写了。

什么情况下会踩这个坑

痛点：相似写法遍布代码库。 一旦出现类似模式，就可能在不同环境下产生隐蔽的数据缺失，而不易被检测到。

-- 这些都会触发调整器把 LEFT JOIN 变成 INNER JOIN
SELECT * FROM t1 LEFT JOIN t2 ON t1.id = t2.id WHERE t2.status = 'active';SELECT * FROM t1 LEFT JOIN t2 ON t1.id = t2.id WHERE t2.amount> 0;SELECT * FROM t1 LEFT JOIN t2 ON t1.id = t2.id WHERE t2.name LIKE '张%';

只要 WHERE 条件里包含了右表的非空列。而且这个条件在 NULL 上返回 false，调整器就会认为外连接可以消除。

有两种情况不会触发：

-- 查右表没有匹配的行，IS NULL 不会被消除
SELECT * FROM t1 LEFT JOIN t2 ON t1.id = t2.id WHERE t2.id IS NULL;-- 条件作用在左表，不会改变外连接的性质
SELECT * FROM t1 LEFT JOIN t2 ON t1.id = t2.id WHERE t1.status = 'active';

查“右表缺失”本来就是 LEFT JOIN 的主要用途，调整器不会动它。其实，条件放在左表上，相当于先从使用者表里筛选出一部分人。再去看这些人有没有订单，也不会消除外连接。

怎么改才靠谱

痛点：错误的 会让问题更难定位。需要明确区分过滤阶段，以避免 丢失数据。

那次翻车之后我养成了一个习惯：凡是 LEFT JOIN 的 SQL。都要单独过一遍，确认不会把数据弄丢。其实，

If business needs to keep all rows from left table

• 把右表的过滤条件从 WHERE 挪到 ON

SELECT *
FROM t1
LEFT JOIN t2
ON t1.id1 = t2.id2 AND t2.name2 = 'cc';

This changes execution order: first filter t2,n perform left join. All rows from t1) are kept;怎么说呢，unmatched rows get NULLs.

If business only needs matched rows

• Avoid LEFT JOIN altoger and use INNER JOIN.

SELECT *
FROM t1
INNER JOIN t2
ON t1.id1 = t2.id2
WHERE t2.name2 = 'cc';话说回来，

This makes intention explicit;optimizer won’t perform any unintended conversion.

This actually reflects two database behaviours

Pain point: Same SQL yields different results on MySQL vs 金仓,causing hidden bugs during migration.

The optimization itself isn’t wrong—turning an outer join into an inner join can be faster. But on MySQL optimizer left outer join intact,while 金仓’s optimizer “helpfully” removed it,breaking business logic.

If you don’t verify such queries before migration,you’ll discover missing rows only after go‑live。which is both embarrassing and costly.

The checklist I now use for every outer‑join query

Pain point: Without a systematic verification process,subtle data‑loss bugs slip through code review and testing phases.

1. Check execution plan. Run EXPLAIN. If a query defined as LEFT JOIN` appears as a hash or nested loop join without preserving outer rows,suspect outer‑join elimination.
2. Create a test row that has no match in right table.

   
   -- Find a left‑table row without a corresponding right‑table row
   SELECT * FROM t1
   WHERE NOT EXISTS
   LIMIT 1;-- Run full query and see if that row is still present
   SELECT * FROM t1
   LEFT JOIN t4 ON ...
   WHERE ...;按理说，

   If it disappears。outer join has been eliminated and you need to rewrite query.
3. Confirm database mode / compatibility settings. 金仓 supports Oracle‑compatible and MySQL‑compatible modes;each may handle outer‑join elimination differently.

   
   SHOW database_mode;

   Make sure mode matches your business expectations before migration.

写在最终

Pain point：跨库迁移最大的风险不是语法不兼容，而是这种隐蔽行为差异导致的数据错漏。一次遗漏十几条记录，就让我们加班一天、重新核对报告、向业务解释原因——这可以通过提前审计和正确写法避免。

那次翻车之后我跟开发团队定了规矩：所有涉及外连接的查询。在代码评审时必须单独检查过滤条件的位置、执行计划是否保持外连接属性，还有在目标库上跑一次完整的数据对比。

`

---