LEFT JOIN加WHERE对右表字段筛选会变INNER JOIN，因WHERE剔除右表NULL行，破坏左表全保留语义；右表条件应写入ON子句，驱动表选过滤性强的表并确保索引与类型一致。
LEFT JOIN四张大表时，为什么一加WHERE就变INNER JOIN
因为WHERE对右表字段做非空判断（比如WHERE c.status = 'active'），数据库会直接剔除所有c为NULL的行——左表“全保留”的语义被破坏，实际执行等效于INNER JOIN。这不是bug，是SQL标准行为。
实操建议：
- 右表筛选条件必须写进对应
ON子句，例如LEFT JOIN c ON a.id = c.a_id AND c.status = 'active' - 若需同时过滤左表和右表，左表条件放
WHERE，右表条件一律进ON - 真要检查右表是否存在匹配？用
WHERE c.id IS NOT NULL是安全的，它只排除无匹配行，不改变JOIN类型
如何避免中间表NULL导致后续JOIN全部失效
连续LEFT JOIN不是链式传递：前一步b没匹配上，b.id就是NULL，下一步ON b.id = c.b_id永远为FALSE，c字段全NULL且无法挽救。
实操建议：
- 每个
ON条件必须独立可判真，不依赖上一步非空值；想让c关联到a，就写ON a.id = c.a_id，别绕道b - 字段别名强制带表前缀，如
c.created_at、b.created_at，避免多层后混淆报错 - 用
EXPLAIN FORMAT=TREE确认c到底在和谁关联，别信肉眼写的顺序
四张大表JOIN卡死，本质是驱动表选错了
优化器面对多个LEFT JOIN常不敢重排顺序，大概率按你写的顺序执行。如果FROM的主表本身没加过滤，又接了一个无索引的宽维表（比如config），就会触发“左表每行 × 右表全扫”，查询耗时线性爆炸。
实操建议：
- 把过滤性最强的表放在
FROM位置，哪怕它不是业务主表；例如有WHERE log.created_at > '2026-09-01'，就让log当驱动表 - 每个右表的
ON字段必须建索引，且类型严格一致（BIGINT对BIGINT，不能VARCHAR对BIGINT） - 对超大维表（如百万级
product），考虑用子查询提前裁剪：LEFT JOIN (SELECT id, name FROM product WHERE category = 'A') p ON ...
字段类型/字符集不一致，索引就白建了
两张表都叫order_id，一个定义为VARCHAR(32)，另一个是BIGINT，MySQL会放弃索引，退化为逐行隐式转换比对——你看到的“慢”，其实是N×M次字符串转数字。
实操建议：
- 用
SHOW CREATE TABLE对比字段定义，统一类型（推荐BIGINT UNSIGNED或带前导零的CHAR(32)） - MySQL 8.0+注意字符集：同是
utf8mb4，utf8mb4_general_ci和utf8mb4_0900_as_cs之间也可能触发隐式转换 - 别在
ON里用函数，如ON DATE(o.created_at) = u.register_date，改用范围：o.created_at >= u.register_date AND o.created_at
LEFT JOIN最易被忽略的点，是默认把“业务主表”当FROM表，却没意识到它可能根本没索引、没分区、也没WHERE过滤——结果整个JOIN从第一秒就开始扫描千万行。真正该前置的，是那个加了时间范围、有分区字段、且ON列已建好复合索引的表。 
