left join比inner join慢的本质是前者强制保留左表全量记录，使优化器无法跳过左表扫描，而后者可利用索引快速排除不匹配行；实操需确认业务是否真需全量左表、右表on字段必建索引、join顺序受索引与统计信息影响。
为什么LEFT JOIN比INNER JOIN慢很多
本质不是JOIN类型本身慢，而是LEFT JOIN强制保留左表全部记录，导致优化器无法跳过左表扫描，即使右表无匹配行也要生成NULL。INNER JOIN可利用索引快速排除不匹配行，执行计划里常出现Using index condition或Using where; Using join buffer。
实操建议：
- 确认业务是否真需要保留左表全量——若实际只关心有匹配的数据，直接换用
INNER JOIN - 避免在LEFT JOIN的右表条件中写
WHERE right_table.id IS NOT NULL，这会让优化器退化为INNER JOIN语义但执行路径未优化，应改写为INNER JOIN - 对LEFT JOIN右表的ON条件字段（如
orders.user_id）必须建索引，否则触发全表扫描
JOIN顺序真的影响性能吗
MySQL 5.7+默认启用join_optimizer，会重排JOIN顺序，但前提是所有表都有可用索引且统计信息准确。一旦某张表缺失关键索引，优化器可能放弃重排，按SQL字面顺序执行——此时小表在前、大表在后反而更糟，因为中间结果集会急剧膨胀。
实操建议：
- 用
EXPLAIN FORMAT=TREE看实际执行顺序，别信SQL书写顺序 - 对驱动表（最左表）优先建覆盖索引，例如
SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id，若常查users.status = 'active'，则建INDEX(status, id) - 用
STRAIGHT_JOIN强制顺序仅当明确知道最优路径时才用，否则干扰优化器
哪些字段必须加索引才能让JOIN快起来
不只是ON子句里的字段。JOIN性能瓶颈常出现在三个位置：驱动表的过滤条件、被驱动表的ON字段、最终SELECT中需排序/分组的字段。缺任意一个，都可能让type降级为ALL或index。
实操建议：
- 被驱动表的ON字段必须单独建索引，例如
orders.user_id不能依赖INDEX(user_id, created_at)的复合索引前缀——除非查询恰好也用到created_at - 如果JOIN后接
ORDER BY created_at LIMIT 20，且created_at在被驱动表，需建INDEX(user_id, created_at)，让索引同时满足JOIN和排序 - 避免在JOIN字段上用函数，例如
ON DATE(o.created_at) = u.register_date会使索引失效，应改用范围查询
EXPLAIN里看到“Using temporary; Using filesort”怎么办
这不是JOIN专属问题，但多表JOIN后数据量变大，极易触发临时表和文件排序。根本原因是MySQL无法利用索引完成GROUP BY或ORDER BY，被迫把中间结果写入磁盘。
实操建议：
- 检查
EXPLAIN输出中的key列是否为NULL，是则说明排序字段没走索引 - 若排序字段在被驱动表，尝试把该表提前为驱动表（配合
STRAIGHT_JOIN验证），或给其建包含JOIN键+排序键的联合索引 - 临时表大小由
tmp_table_size和max_heap_table_size共同控制，调高可能让临时表留在内存，但治标不治本
复杂点在于：索引设计要同时兼顾JOIN路径、过滤条件、排序需求，三者稍有错位，EXPLAIN就立刻暴露。很多人只盯着ON字段建索引，却忘了后面那个ORDER BY才是真正的性能杀手。
