MySQL JOIN性能关键在驱动表WHERE条件和被驱动表ON字段是否命中索引，驱动表过滤后行数过多则JOIN优化无效。
WHERE 条件字段没加索引，JOIN 就白搭
MySQL 的 JOIN 本身不直接走索引，真正决定性能的是驱动表（左表）的 WHERE 条件是否能用上索引，以及被驱动表（右表）的 ON 关联字段是否有索引。如果 WHERE 过滤后驱动表仍返回几万行，再怎么优化 ON 字段也没用。
实操建议：
- 先确认驱动表的过滤条件字段（比如
user.status = 'active'）是否在user表上有索引 —— 单列索引或联合索引的最左前缀都行 - 被驱动表的关联字段（如
orders.user_id）必须有索引，否则会触发ALL扫描，Explain 里看到type: ALL就是它 - 避免在
ON或WHERE中对字段做函数操作，例如ON DATE(o.create_time) = '2024-01-01'会让create_time索引失效
多表 JOIN 时驱动表选错，性能断崖式下跌
MySQL 默认按 FROM 后顺序选择驱动表（左深树），但优化器可能因统计信息不准而选错。比如 SELECT ... FROM large_table JOIN small_table ON ...，若 large_table 没有效过滤条件，就会拿它当驱动表，导致对 small_table 做几百万次嵌套循环查找。
实操建议：
- 用
EXPLAIN FORMAT=TRADITIONAL查看table列顺序和rows预估，重点关注驱动表的rows是否远超预期 - 强制指定驱动表：用
STRAIGHT_JOIN（仅限 INNER JOIN），写成SELECT STRAIGHT_JOIN ... FROM small_table JOIN large_table ON ... - 给小结果集的表加
FORCE INDEX，例如FROM orders FORCE INDEX (idx_user_status) JOIN users ON ...
ON 和 WHERE 混用导致索引失效或语义错误
LEFT JOIN 中，把本该写在 WHERE 的过滤条件错放 ON 子句，不仅可能让索引无法生效，还会改变结果逻辑。比如 LEFT JOIN orders ON u.id = o.user_id AND o.status = 'paid'，这条 o.status = 'paid' 是关联条件的一部分，不是过滤条件 —— 它会让 orders 表只匹配已支付订单，但依然保留用户；而写成 WHERE o.status = 'paid' 就会把没订单或订单未支付的用户全过滤掉。
实操建议：
-
ON只放关联逻辑（u.id = o.user_id）和被驱动表的「窄化关联范围」条件（如o.deleted = 0），前提是该字段有索引且能减少匹配行数 -
WHERE放最终结果过滤，尤其是驱动表字段的条件必须在这里写，否则 LEFT JOIN 可能退化为 INNER JOIN - 如果被驱动表的
ON条件含非等值判断（如o.amount > 100），MySQL 通常无法用索引加速关联，应尽量避免
联合索引顺序不对，覆盖不了 JOIN + WHERE 组合场景
比如查询 SELECT u.name, o.amount FROM users u JOIN orders o ON u.id = o.user_id WHERE u.city = 'Shanghai' AND u.status = 'active'，如果只在 users 表建了 (status, city) 索引，那 city 字段就用不上最左前缀，导致全表扫描。
实操建议：
- 联合索引顺序按「过滤性高 + 出现在 WHERE 的频率高」排序，例如
city区分度通常高于status，优先放前面：(city, status) - 如果查询还带
ORDER BY u.created_at，可扩展为(city, status, created_at)，实现“索引覆盖”，避免回表 - 对被驱动表，
ON字段必须是联合索引的第一列，例如orders(user_id, status)能用于ON o.user_id = u.id，但(status, user_id)就不行
EXPLAIN SELECT u.name, o.amount FROM users u STRAIGHT_JOIN orders o ON u.id = o.user_id WHERE u.city = 'Shanghai' AND u.status = 'active' AND o.status = 'paid';
复杂点往往不在语法，而在你没意识到驱动表的 rows 预估偏差有多大，或者 EXPLAIN 里那个 key_len 值已经暴露了索引只用了一半。别急着改 SQL，先看执行计划里哪一行在扫全表。
