JOIN 关联字段无索引会导致嵌套循环全表扫描，性能骤降十倍；所有ON子句字段（非常量/表达式）必须单独建索引或作联合索引最左前缀，且左右表均需覆盖，否则易退化为ALL扫描。
JOIN 字段没索引，查询直接变慢十倍
MySQL 执行 JOIN 时，如果关联字段（比如 ON t1.user_id = t2.id 中的 user_id 和 id）没有索引，优化器大概率会走嵌套循环（Nested Loop），对小表每行都扫描大表全量——哪怕只有 1 万行，也可能触发千万级扫描。这不是“有点慢”，是“查不出结果等超时”。
实操建议：
- 所有
ON子句中出现的字段，只要不是常量或表达式（如ON t1.id = 123），必须单独建索引或作为联合索引最左前缀 - 注意方向：
t1.a = t2.b要求t1.a有索引，t2.b也得有；少一个，就可能退化为全表扫描 - 用
EXPLAIN看type列：出现ALL或index（非覆盖索引）基本就是没走对路
联合索引顺序决定 JOIN 效率上限
当 WHERE 条件和 JOIN 条件共存时（比如 SELECT * FROM orders o JOIN users u ON o.user_id = u.id WHERE u.status = 'active' AND o.created_at > '2024-01-01'），索引设计不能只看 ON 字段。
实操建议：
- 优先把
JOIN字段放在联合索引最左边，因为 MySQL 的ON匹配发生在WHERE过滤之前；例如INDEX(user_id, status)比INDEX(status, user_id)更适合这个场景 - 如果
WHERE条件区分度极高（比如唯一 ID），而JOIN字段区分度低（比如category_id），可以考虑先过滤再关联，但前提是能控制驱动表顺序（用STRAIGHT_JOIN或调整表顺序） - 别迷信“一个索引管所有”：
INDEX(a,b,c)对WHERE a=1 AND b=2有效，但对JOIN ON b=x无效——b不是最左前缀
LEFT JOIN 的右表字段加索引，容易被忽略
很多人给左表字段加了索引，却忘了 LEFT JOIN 的右表（t2）字段也要索引。尤其当右表数据量大、且 ON 条件不唯一时（比如一对多），没索引会导致右表重复扫描。
常见错误现象：
-
EXPLAIN显示右表type=ALL，但左表是ref - 加了
WHERE t2.xxx IS NOT NULL后性能反而更差——因为优化器可能放弃使用左连接语义，转而尝试改写为INNER JOIN，但右表仍无索引 - 右表有
ORDER BY或LIMIT，但排序/截断发生在关联之后，无法利用索引加速
实操建议：
- 右表的
ON字段必须单独建索引，即使它是主键（主键索引只对等值查询高效，若涉及范围或排序仍可能失效） - 如果右表还要
ORDER BY some_col，且该列在ON字段之后高频出现，可建INDEX(join_col, some_col)
小表驱动大表？不一定，得看索引和统计信息
“用小表做驱动表”是老经验，但在有索引的前提下，MySQL 优化器通常能自动选对驱动表。强行用 STRAIGHT_JOIN 反而可能绕过索引选择逻辑，导致更差执行计划。
实操建议：
- 先确保所有关联字段都有索引，再看
EXPLAIN输出的table顺序和rows预估——如果预估行数严重偏离实际（比如显示 1 行，实际扫描 10 万行），说明统计信息过期，运行ANALYZE TABLE - 只有当明确知道优化器选错了（比如本该用索引却走了全表），且已验证新顺序确实更快，才用
STRAIGHT_JOIN锁定驱动表 - 注意：5.7+ 版本中，
JOIN顺序受optimizer_switch中join_cache_level和block_nested_loop影响，盲目调参不如先理清索引
真正卡住性能的，往往不是 JOIN 本身，而是关联字段上缺失的那一个索引，或者联合索引里错位的一个字段顺序。检查时别只盯 SQL 写法，先翻 EXPLAIN 里的 key 和 rows 列。
