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