JOIN变慢主因是WHERE或ON字段缺失索引，导致全表扫描；需为过滤和关联字段建合适索引，右表条件应移入ON子句，并用EXPLAIN验证优化效果。
WHERE 条件字段没加索引，JOIN 就容易变慢
绝大多数 JOIN 查询变慢，不是因为 JOIN 本身，而是驱动表（通常是 LEFT JOIN 左侧或 INNER JOIN 任一侧）的
条件字段没走索引，导致扫描全表后再去关联——相当于先读几百万行，再逐行去另一张表找匹配。
实操建议：
用
看
列：如果是
或
，基本说明没走有效索引
中参与过滤的字段（如
、
），必须在对应表上建单列或联合索引
注意隐式类型转换：比如
是
，但传了字符串
，MySQL 可能放弃索引——检查
的
和
是否一致
联合索引顺序很重要：
能加速
，但对
无效
ON 子句里的字段必须两边都有索引
JOIN 的性能瓶颈常卡在「怎么快速从被驱动表找到匹配行」。如果
，而
没索引，MySQL 就得对每一条
结果，全表扫一遍
—— 数据量一上去，秒变“慢查询”。
实操建议：
中涉及的每个字段，各自所在表都应有索引（哪怕只是单列索引）
不要依赖“主键自动有索引”就忽略外键字段：比如
是外键，但没显式建索引，照样不加速 JOIN
复合条件如
，优先考虑在
上建联合索引
，比两个单列索引更稳
注意 NULL 值影响：如果
允许 NULL 且实际有很多 NULL，即使有索引，优化器也可能放弃使用——可加
显式排除
LEFT JOIN 后加 WHERE 条件，可能让索引失效甚至转成 INNER JOIN
这是最隐蔽的坑：
表面上是左连接，但
对右表字段过滤后，所有
为 NULL 的订单都会被干掉，实际效果等价于
，而且很可能因
无索引导致全表扫描右表。
实操建议：
右表的过滤条件，尽量写进
子句，而不是
：把
改成
如果真需要保留 NULL 行（比如统计所有订单，不管用户状态），又得按状态筛选，那就拆成子查询或 CTE，先过滤右表再 JOIN
执行前务必
对比：改完前后看
和
是否明显改善
小表驱动大表不总是对的，要看过滤后的真实行数
老经验说“用小表做驱动表”，但实际中，真正决定快慢的是「JOIN 前经过 WHERE 过滤后，哪边结果集更小」。一张号称“小”的字典表，如果
匹配了 80% 行，它就不再是小表。
实操建议：
别只看表总行数，用
估算过滤后行数
当两表都带强过滤条件时，让选择性更高（即过滤后剩余比例更小）的那张表当驱动表
MySQL 8.0+ 的哈希连接（Hash Join）在某些场景下会自动绕过驱动表逻辑，但前提是没用到
、
或无法下推的函数——别默认它一定生效
如果发现优化器选错了驱动表，可用
强制顺序，但仅限调试；长期方案还是补索引或重写条件提升选择性
索引不是越多越好，JOIN 的关键永远是“让每次查找都落在索引 B+ 树的少数几层里”。很多慢查修复，其实只差一个缺失的单列索引，或者把 WHERE 条件挪进 ON 里——但这两处，恰恰最容易被忽略。
WHEREEXPLAINtypeALLindexWHEREuser_id = ?status IN ('active', 'pending')user_idBIGINT'123'EXPLAINpossible_keyskey(a, b, c)WHERE a = ? AND b > ?WHERE b = ?ON t1.id = t2.user_idt2.user_idt1t2ONt2.user_idON t1.a = t2.x AND t1.b = t2.yt2(x, y)t2.user_idWHERE t2.user_id IS NOT NULLLEFT JOIN users u ON o.user_id = u.id WHERE u.status = 'active'WHEREu.idINNER JOINu.statusONWHEREWHERE u.status = 'active'ON o.user_id = u.id AND u.status = 'active'EXPLAINrowskeyWHERE type = 'xxx'SELECT COUNT(*) FROM t WHERE ...ORDER BYLIMITSTRAIGHT_JOIN