为什么MySQL在关联查询时驱动表的选择直接影响索引效率

驱动表选错会导致被驱动表索引失效；NLJ仅在被驱动表关联字段有索引时生效，索引只加速被驱动表单行查找，不加速驱动表遍历。

驱动表选错，被驱动表的索引根本用不上

MySQL的Index Nested-Loop Join（NLJ）只在被驱动表的关联字段有索引时才生效。如果优化器误把大表当驱动表、小表当被驱动表，而小表恰好没建索引——那整个JOIN就退化成Block Nested-Loop Join或Hash Join，索引形同虚设。

关键点在于：**索引只加速“被驱动表”的单行查找，不加速驱动表的遍历**。驱动表走全表扫描或范围扫描，被驱动表才靠索引定位匹配行。所以哪怕b.id上有主键索引，只要b被当成驱动表，这个索引在JOIN阶段就完全不会参与匹配逻辑。

• LEFT JOIN中左表固定是驱动表，所以ON条件里右表的字段必须有索引
• INNER JOIN中优化器按WHERE过滤后的结果集大小选驱动表，不是按物理表大小——WHERE status = 'active'后只剩100行的“大表”，也可能被选为驱动表
• 如果连接字段类型不一致（比如INT vs VARCHAR），MySQL会隐式转换，导致被驱动表索引失效，即使建了也没用

EXPLAIN里看驱动顺序比看表名更可靠

EXPLAIN输出中，id相同且select_type为SIMPLE的行，从上到下就是实际执行顺序：上面的是驱动表，下面是被驱动表。别只盯着FROM a JOIN b就认定a是驱动表——优化器可能重排。

重点看type和Extra字段：

• type为ALL或index → 驱动表正在全表/索引扫描
• type为ref/eq_ref/range → 被驱动表走了索引查找
• Extra含Using join buffer → 没走索引，触发Block Nested-Loop Join
• Extra含Using where; Using index → 被驱动表命中覆盖索引，效率最高

小表驱动大表 ≠ 物理小表，而是过滤后结果集最小

真正影响NLJ效率的，是驱动表最终要循环多少次。假设orders有1000万行，但WHERE created_at > '2026-06-01'后只剩50行；users只有10万行，但没加WHERE，全量参与。这时优化器大概率选orders当驱动表——外层只循环50次，每次用user_id索引查users，总开销远小于反过来。

• 用SELECT COUNT(*)配合相同WHERE条件预估驱动表结果集大小
• 对驱动表的WHERE条件字段建索引，能进一步缩小其扫描范围
• 避免在驱动表上用SELECT *，减少join_buffer内存压力，尤其当它意外变大时

被驱动表索引不是建了就完事，得看查询路径

即使user_id字段建了索引，如果JOIN条件写成ON CAST(o.user_id AS CHAR) = u.id，或者ON o.user_id + 0 = u.id，都会触发隐式转换，索引失效。同样，如果被驱动表需要回表（比如SELECT *但索引不是覆盖索引），性能也会打折扣。

• 确保JOIN字段类型完全一致：TINYINT对TINYINT，VARCHAR(32)对VARCHAR(32)，字符集也要相同
• 优先用主键或唯一索引做JOIN字段，避免二级索引+回表
• 若被驱动表需返回大量非索引列，考虑添加覆盖索引，例如INDEX(user_id, name, email)

真正卡住性能的，往往不是“有没有索引”，而是“索引在不在被驱动表上、有没有被正确触达”。一次EXPLAIN就能暴露问题，但很多人直接跳过这步，转头去调join_buffer_size——方向错了，调再久也没用。