MySQL优化器仅在LEFT JOIN语义等价于INNER JOIN时将其转换：右表字段有NOT NULL约束，且WHERE中含右表IS NOT NULL等非空过滤，无OR/聚合等干扰结构。
MySQL优化器不会对“简单的LEFT JOIN”做内连接消除——除非你写的LEFT JOIN语义上等价于INNER JOIN，且满足严格条件。 这是常见误解的源头：不是优化器“主动消除”，而是它识别出你的LEFT JOIN实际不产生NULL补行，于是安全地改写为INNER JOIN来启用更多优化路径（比如表顺序重排、索引选择更自由）。
什么情况下LEFT JOIN会被转成INNER JOIN？
必须同时满足以下全部条件，优化器才可能触发该转换：
-
ON条件中右表字段有NOT NULL约束，且 - WHERE子句中包含对右表字段的
IS NOT NULL或等值非NULL判断（如cb.c_id > 0），且 - 没有
OR、UNION、聚合、GROUP BY等阻止转换的结构
典型例子：SELECT c.name FROM customer c LEFT JOIN customer_balances cb ON c.id = cb.c_id WHERE cb.c_id IS NOT NULL。这里WHERE cb.c_id IS NOT NULL直接过滤掉了所有左表独有行，LEFT JOIN语义已退化为INNER JOIN。
为什么转成INNER JOIN能提升性能？
关键在于驱动表选择自由度：
- LEFT JOIN强制左表为驱动表，哪怕它比右表大十倍也必须全扫；
- INNER JOIN允许优化器选小表当驱动表，大幅减少被驱动表的匹配次数；
- 转换后可能启用
Batched Key Access (BKA)或更优的Index Nested-Loop Join，而原LEFT JOIN在右表无索引时只能走Block Nested Loop（BNL）； -
EXPLAIN中可见type从ALL变为ref或range，Extra里消失Using join buffer
容易踩的坑：你以为在用LEFT JOIN，其实已被悄悄改写
这会导致两个隐蔽问题：
- 结果集意外变少：如果右表某行
c_id为NULL，但WHERE里写了cb.c_id > 0，那整行被过滤——LEFT JOIN本应保留左表记录并补NULL，现在却丢了； - 执行计划不可预测：加一个看似无害的
WHERE cb.status = 'active'（且status列无NOT NULL约束），转换就不会发生；但若该列建了NOT NULL约束，转换又突然生效； - 索引失效风险：转换后优化器可能选错索引，尤其当右表有复合索引但查询只用到前缀列时
验证是否被转换，最直接的方法是执行EXPLAIN FORMAT=TRADITIONAL，看select_type是否从DEPENDENT SUBQUERY或SIMPLE变成PRIMARY，以及Extra字段是否出现Not exists或Using where; Using index这类INNER JOIN特征标记。
真正需要LEFT JOIN语义时，务必把右表的过滤条件全写进ON子句，而不是WHERE——这是最容易被忽略、也最影响结果正确性的操作。
