驱动表是explain输出中table列从上到下的第一行所对应的表，即mysql实际最先扫描的表；若其type为all或index、rows异常高且key为null，说明优化器误判，需结合straight_join验证并优先补索引修复根本问题。
怎么看EXPLAIN里谁是真正的驱动表
别信SQL写的顺序，只看EXPLAIN输出中table列从上到下的第一行——它才是MySQL实际执行时最先扫描的表，也就是驱动表。如果第一行的type是ALL或index，且rows高达几十万，而它本该被WHERE条件过滤到几十行（比如goods WHERE tid = 888），说明优化器已经选错。
常见误判信号包括：
-
Extra列出现Using join buffer (Block Nested Loop)，基本坐实被驱动表太大、被迫缓存 - 小表那行
rows异常高（如显示280000），说明没走索引、被当成了被驱动表去循环扫描 - 大表在第一行且
key为NULL，而小表在第二行且有可用索引
用STRAIGHT_JOIN强制换序并对比执行计划
在Navicat中右键SQL → “解释”，记下原始EXPLAIN的rows总和与Extra内容；然后改写SQL，在SELECT后紧接STRAIGHT_JOIN，确保你想当驱动表的表出现在FROM最左侧：
SELECT STRAIGHT_JOIN u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id WHERE u.status = 'active';
注意以下几点：
-
STRAIGHT_JOIN必须紧跟SELECT，写成SELECT * FROM users u STRAIGHT_JOIN orders o无效 - 不支持子查询包裹的表，如
FROM (SELECT * FROM users) u会让STRAIGHT_JOIN完全失效 - 只对
SELECT有效，UPDATE或DELETE加了也白加
对比时重点盯哪几项指标
两次EXPLAIN结果不能只比“快不快”，要横向对齐看三处：
-
rows列：不是单行值，而是各表rows相乘后的理论扫描量（尤其关注被驱动表那行的rows是否大幅下降） -
key列：被驱动表的ON字段是否命中索引（如user_id没索引，换再多次序也没用） -
Extra列：是否从Using join buffer变成Using index或直接消失
如果换了顺序后rows没变，大概率是关联字段类型不一致（比如INT对VARCHAR）、字符集不同（utf8mb4对utf8），或ON条件用了函数（如DATE(o.create_time)），这些都会让索引失效，强制顺序也救不了。
为什么对比完还不能直接上线STRAIGHT_JOIN
它只是验证手段，不是长期解法。因为：
- 数据分布会变——今天小表明天暴涨十倍，硬编码顺序反而更慢
- 统计信息过期会导致优化器持续误判，应先运行
ANALYZE TABLE users, orders - 真正稳的解法是给被驱动表的
ON字段补索引（如orders(user_id)），并把高频过滤条件写进对应表的WHERE子句（如WHERE orders.status = 'paid'紧贴orders定义）
STRAIGHT_JOIN临时有效，但容易掩盖索引缺失或类型不一致这类根本问题——这些坑一旦漏掉，下次换表结构或升级MySQL版本，性能可能突然崩掉。
