left join性能不如inner join，核心在于其语义强制左表全量扫描且驱动表顺序被锁死，优化器无法跳过左表或交换连接顺序，导致右表索引难生效、i/o开销倍增。

LEFT JOIN 性能不如 INNER JOIN，核心不是语法本身慢，而是驱动表扫描开销被迫放大——左表全量必须参与关联，优化器没法跳过，更难用上右表索引。

LEFT JOIN 的驱动表为什么总是“被锁死”

MySQL/PostgreSQL 的 JOIN 执行顺序受语义约束：LEFT JOIN 的左表（FROM 后第一个表）几乎必然成为驱动表。优化器不能像处理 INNER JOIN 那样自由交换顺序，哪怕右表更小、有更好索引，也得先扫左表每行，再逐条去右表找匹配。

• 写 FROM orders LEFT JOIN customers ON ... → orders 就是驱动表，哪怕它有 1000 万行
• INNER JOIN 中，优化器可能选 customers 当驱动表（如果它只有 1 万行），大幅减少循环次数
• 驱动表行数越多，右表被访问的次数就越多；若右表没索引，就是 N × M 级 I/O

ON 条件写错，直接让右表索引失效

即使右表字段建了索引，只要 ON 子句里出现隐式转换或函数，索引就退化为全表扫描。LEFT JOIN 下这问题更致命——因为驱动表行数多，扫一次右表的成本被放大了 N 倍。

• ON t1.id = CAST(t2.ref_id AS CHAR) → t2.ref_id 索引无法使用
• ON t1.code = UPPER(t2.code) → 函数导致索引失效
• ON t1.user_id = t2.user_id AND t2.status = 'active' → 复合条件中 t2.status 不在索引最左列，Seek 可能变 Scan

WHERE 条件放错位置，LEFT JOIN 白白多扫一遍

这是最隐蔽也最常踩的坑：LEFT JOIN ... WHERE t2.col IS NOT NULL 或 WHERE t2.status = 'done'，表面看只是过滤，实际让整个 LEFT JOIN 语义退化为 INNER JOIN，但执行计划仍按左连接逻辑生成——左表全扫、右表全连、最后再筛，三步全做。

• 错误写法：LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid' → 实际等价于 INNER JOIN，但多花了左表扫描成本
• 正确写法：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' → 过滤提前到连接阶段，右表只读匹配行
• 验证方法：EXPLAIN 中看 rows 和 filtered，若 rows 接近左表总行数，基本就是被拖累了

统计信息过期会让 LEFT JOIN 更“瞎”

优化器依赖统计信息估算行数，决定是否走 Nested Loops、Hash Match 还是 Merge Join。LEFT JOIN 对估算更敏感——一旦低估右表匹配率，它可能选错算法，比如该用 Index Seek 却用了 Table Scan。

• 执行 ANALYZE TABLE users, orders（MySQL）或 VACUUM ANALYZE（PostgreSQL）更新统计
• 特别注意：大表批量导入后没 ANALYZE，LEFT JOIN 很容易选错驱动表或连接方式
• 某些场景下，optimizer_search_depth 设得太低（如 MySQL 默认 6），长 JOIN 链直接放弃重排，硬按书写顺序执行

LEFT JOIN 的性能瓶颈不在“要不要 NULL”，而在“不得不扫”。真正要优化的，从来不是换 JOIN 类型，而是控制驱动集大小、确保右表能 Seek、把过滤逻辑塞进 ON——否则你写的 LEFT JOIN，很可能正在替 INNER JOIN 承担双倍开销。