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里混用非等值条件（如、<code>BETWEEN），它们无法下推，容易导致驱动表选择失衡 - 多表JOIN时，
ON条件只作用于当前两个表，不会自动传播到更早或更晚的表——所以顺序决定了哪些条件能“及时生效”
索引覆盖与连接字段类型不一致的连锁反应
哪怕两张表都对连接字段建了索引，只要类型不一致（比如users.id是BIGINT，orders.user_id是VARCHAR），MySQL就会放弃索引查找，改走全表扫描。这时JOIN顺序就放大了问题：如果你把类型不一致的大表放在前面，它就成了事实上的驱动表，整个查询性能雪崩。
- 用
SHOW CREATE TABLE核对所有ON字段的类型和长度是否完全一致，包括是否有unsigned、CHARSET差异 - 字符集不一致（如
utf8mb4vsutf8）也会导致隐式转换，使索引失效 - 执行
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的书写顺序本身。
