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' 就会把没订单或订单未支付的用户全过滤掉。
