MySQL优化器基于成本模型选择驱动表，优先选预估扫描行数（rows）最小且过滤后参与JOIN行数最少的表；EXPLAIN中type为ALL或index、排在table列首位的即为实际驱动表。

MySQL优化器如何选择驱动表

执行计划里哪个表先被扫描，不取决于你写在FROM还是第几个INNER JOIN，而取决于优化器估算的“成本最低”路径。但你的书写顺序会显著影响它的估算——尤其当统计信息不准、索引缺失或表大小差异大时，优化器容易误判。比如你把大表写在前面、小表写在后面，它可能默认用大表做驱动表，导致嵌套循环连接（Nested Loop）反复扫描小表索引数十万次。

• 驱动表通常是EXPLAIN输出中table列排第一、type为ALL或index的那张表
• 若所有连接字段都有等值条件且有索引，优化器大概率按数据量升序选驱动表；但一旦某张表没索引，它可能退化为全表扫描+临时表，顺序就变得敏感
• STRAIGHT_JOIN可强制固定连接顺序，但仅在你确认优化器判断错误时才用，否则会绕过统计信息更新带来的后续收益

ON子句条件是否能下推到驱动表扫描阶段

优化器能否把ON里的条件提前应用到单表扫描中，直接决定要不要走全表扫描。比如：orders INNER JOIN users ON orders.user_id = users.id WHERE users.status = 'active'，如果users是驱动表且status有索引，这个WHERE就能变成users的过滤条件；但如果把users写在后面，优化器可能延迟到JOIN之后再过滤，白白加载大量无效行。

• 把带强过滤条件（如status = 'active'、created_at > '2025-01-01'）的表尽量前置，让其作为驱动表
• 避免在ON里混用非等值条件（如、BETWEEN），它们无法下推，容易导致驱动表选择失衡
• 多表JOIN时，ON条件只作用于当前两个表，不会自动传播到更早或更晚的表——所以顺序决定了哪些条件能“及时生效”

索引覆盖与连接字段类型不一致的连锁反应

哪怕两张表都对连接字段建了索引，只要类型不一致（比如users.id是BIGINT，orders.user_id是VARCHAR），MySQL就会放弃索引查找，改走全表扫描。这时JOIN顺序就放大了问题：如果你把类型不一致的大表放在前面，它就成了事实上的驱动表，整个查询性能雪崩。

• 用SHOW CREATE TABLE核对所有ON字段的类型和长度是否完全一致，包括是否有unsigned、CHARSET差异
• 字符集不一致（如utf8mb4 vs utf8）也会导致隐式转换，使索引失效
• 执行EXPLAIN FORMAT=TREE（MySQL 8.0+）能直接看到“Using join buffer”或“Impossible WHERE”，这是驱动表选错或条件未下推的典型信号

为什么加了WHERE却让INNER JOIN变慢

很多人以为WHERE只是最后过滤结果，其实它可能倒逼优化器换驱动表。例如：SELECT * FROM orders o INNER JOIN users u ON o.user_id = u.id WHERE u.name LIKE 'A%'，如果users.name没有索引，优化器发现无法高效定位u，就可能反向选择orders做驱动表，再对每条订单去users里模糊匹配——这比原本的等值JOIN慢几个数量级。

• WHERE条件若涉及右表字段，且该表无合适索引，大概率触发Using where; Using join buffer，说明在内存里做哈希匹配，极易OOM
• 把WHERE条件尽可能挪到驱动表上，并确保对应字段有索引；否则考虑用FORCE INDEX或重写为子查询提前过滤
• 多表JOIN后加GROUP BY或ORDER BY，会进一步限制优化器的选择空间，顺序影响会被放大

真正难的不是记住“小表放前”，而是看懂EXPLAIN里哪一行在扫全表、哪个key是NULL、为什么rows预估和实际相差十倍——这些细节藏在执行计划的每一列里，而不是SQL的书写顺序本身。