LEFT JOIN比INNER JOIN慢得多，根本原因在于其语义强制全量扫描左表且无法跳过无关行，优化器不能下推右表过滤条件，导致I/O和内存开销剧增；典型表现为EXPLAIN中左表type=ALL或右表rows异常高。
LEFT JOIN 为什么比 INNER JOIN 慢得多
不是语法本身慢，而是数据库必须扫描左表全部行——哪怕你最终只想要最近7天的订单。优化器无法跳过左表中那些“注定不会出现在结果里”的行，更没法把右表的 WHERE 条件下推到关联前执行。典型表现是 EXPLAIN 里左表 type=ALL 或右表 rows 高得离谱。
常见错误现象：
- 加了
WHERE order_time > '2026-09-23'，但执行计划显示仍扫描几千万行订单 - 左表 100 万行，右表 50 万行，结果集暴涨到 800 万行（一对多膨胀）
- 明明右表有索引，
EXPLAIN却显示type=ALL，说明索引没被用上
把过滤条件提前到子查询里再 JOIN
这是见效最快、风险最低的改法。核心逻辑：不让数据库先扛着全量数据去关联，而是先裁剪出真正要参与 JOIN 的数据子集。
实操建议：
- 左表过滤写成派生表：
(SELECT id, name FROM users WHERE dept = 'tech')，而不是FROM users WHERE dept = 'tech'放最后 - 右表过滤必须用子查询包裹：
LEFT JOIN (SELECT user_id, amount FROM orders WHERE create_time > '2026-09-01') o ON u.id = o.user_id - 避免在子查询里用
SELECT *，只选 JOIN 和后续需要的字段，减少内存和网络开销 - 子查询别名要明确，否则某些 MySQL 版本会报
Every derived table must have its own alias
ON 条件里别乱塞右表的非关联过滤
ON 是定义“怎么连”，WHERE 是定义“哪些行留下”。把右表的业务过滤条件（比如 status = 'done'）错放到 ON 里，语义上仍保留左表空匹配，但性能未必提升——因为数据库仍可能扫描右表全量来判断每行是否满足 AND status = 'done'。
实操建议：
- 如果目标是“只关联已完成订单，同时保留无订单用户”，就该写：
LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'done' - 如果目标是“只看有已完成订单的用户”，那就直接换
INNER JOIN，别硬撑LEFT JOIN+WHERE o.status = 'done'，后者实际已退化为内连接，但执行路径没优化 - 检查右表
ON字段类型是否与左表严格一致，BIGINT对VARCHAR会导致隐式转换，索引失效
索引建在哪、建什么类型才真有用
LEFT JOIN 的右表索引，必须覆盖 ON 中所有等值条件字段，且顺序要匹配。单列索引对复合 ON 条件基本无效。
实操建议：
- 右表
ON a.id = b.a_id AND b.status = 'active'→ 索引必须是(a_id, status)，不能只是(status)或(a_id) - 左表用于 JOIN 的字段也建议有索引，尤其当它被多个 LEFT JOIN 复用时，避免重复排序或临时表
- 如果查询还带
ORDER BY或LIMIT，考虑把排序字段加入右表索引尾部，形成覆盖索引，避免回表 - MySQL 8.0+ 可用
FORCE INDEX强制走某索引，但仅限右表单表，且上线前必须压测验证效果
最容易被忽略的一点：统计信息过期。即使索引建对了、SQL 写对了，如果 ANALYZE TABLE 没跑过，优化器看到的还是旧的行数估算，可能继续选择嵌套循环而非哈希连接。别只盯着 SQL 和索引，定期更新统计信息才是让优化器“看得清”的前提。
