驱动表是explain中rows最小且id为1的表；left join左表强制驱动，inner join才可由优化器选择；被驱动表on字段必须有匹配索引且类型完全一致，否则小表驱动无效。
驱动表选错，哪怕只多扫几万行，查询就可能从毫秒级拖到秒级——这不是夸张，而是MySQL执行器真实行为。
EXPLAIN里哪一行才是真正的驱动表？
别被SQL写法或表顺序骗了。驱动表是EXPLAIN输出中rows值最小的那张表，且它一定出现在第一行（id为1）。这个rows代表该表经过WHERE过滤后预估返回的行数，不是原始数据量。
- 如果
EXPLAIN显示大表在第一行、rows却高达50万，说明WHERE条件没生效，或者统计信息过期，该跑ANALYZE TABLE了 -
LEFT JOIN下左表强制当驱动表，哪怕它rows很大，优化器也不能换；INNER JOIN才允许优化器按rows挑最小的 - 用
STRAIGHT_JOIN前先确认：你比优化器更清楚实际数据分布，否则可能把100行驱动强行改成10万行驱动
被驱动表没索引，小表驱动也救不了命
驱动表小只减少外层循环次数，但内层匹配若全表扫描，性能照样崩。关键看被驱动表ON字段有没有索引。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
-
JOIN orders o ON u.user_id = o.user_id→orders.user_id必须有索引（主键/唯一/普通都行） - 复合ON条件如
ON t1.a = t2.x AND t1.b = t2.y→t2上要建INDEX(x, y)，顺序不能颠倒 -
INDEX(a, b, c)无法加速ON t2.b = ?，因为b不是最左前缀 -
LEFT JOIN右表、RIGHT JOIN左表最容易漏建索引，务必逐个检查ON字段
字段类型不一致直接让索引失效
哪怕只是INT和UNSIGNED INT、VARCHAR(50)和VARCHAR(100)、一边字符串一边数字，MySQL都可能触发隐式转换，导致被驱动表索引完全不走。
- 查
EXPLAIN的type字段：如果是ALL或index，而不是ref/range，大概率是类型不匹配或索引没建对 - 用
SHOW CREATE TABLE核对两边字段定义，确保类型、长度、符号性（signed/unsigned）完全一致 - 字符串字段关联时，注意字符集和排序规则（collation）是否相同，不同也可能拒绝走索引
真正卡住性能的，往往不是“该不该小表驱动”，而是被驱动表的索引建没建对、字段类型配没配准——这两点漏掉一个，前面所有驱动表选择都白搭。
