EXPLAIN第一行显示的表才是实际驱动表，优化器按成本而非SQL书写顺序选择；驱动表是过滤后结果集最小的表，而非物理小表。
EXPLAIN第一行才是真正的驱动表，别信SQL写法顺序
MySQL优化器不按你写的LEFT JOIN或INNER JOIN顺序执行，它只看成本。你写的SELECT * FROM users u LEFT JOIN orders o ON u.id = o.user_id，EXPLAIN第一行显示的表才是实际驱动表——可能是orders，哪怕它有500万行。这是最常被忽略的前提：语法 ≠ 执行逻辑。
常见错误现象：
- LEFT JOIN左表是大表，右表有强WHERE条件（如
WHERE o.status = 'paid'），但EXPLAIN显示左表type=ALL、右表type=ref，响应却极慢 - 明明加了索引，
key列却显示NULL，说明该表根本没走索引扫描，而是被当作了驱动表全扫
验证方法只有两个：
- 用
EXPLAIN FORMAT=TREE（MySQL 8.0+），最外层节点就是驱动表 - 在测试环境开
optimizer_trace，查chosen_range_access_summary段，看优化器“为什么选它”
驱动表不是“小表”，而是“过滤后结果集最小的表”
优化器真正比较的不是原始表大小，而是应用WHERE条件后的预估行数。比如log表有1亿行，但WHERE created_at > '2024-09-01'后只剩2000行；而user表仅10万行，但没加任何过滤——这时log更可能成为实际驱动表。
实操建议：
- 把带强过滤条件的表放在FROM后第一位，哪怕它是业务上“从属”的维表
- 避免在WHERE中对右表字段过滤（如
LEFT JOIN t2 ON t1.id = t2.id WHERE t2.status = 'ok'），这会让优化器转为INNER JOIN语义，同时失去对左表保全性的控制 - ON条件只做关联，不做过滤；WHERE才负责最终筛选——这是LEFT JOIN不退化的底线
被驱动表必须有匹配的索引，且类型不能隐式转换
驱动表确定后，性能瓶颈几乎全落在被驱动表的访问效率上。如果它没走索引，就会变成嵌套循环里的全表扫描，代价是驱动表行数 × 被驱动表总行数。
关键检查点：
-
ON字段类型必须严格一致：比如a.id是BIGINT，b.ref_id就不能是VARCHAR，否则触发隐式转换，索引失效 - 被驱动表的连接字段（如
orders.user_id）必须有单列索引，或作为联合索引的最左前缀；若还有WHERE b.status = 'active'，则推荐建INDEX (user_id, status) - 不要在ON里用函数：
ON UPPER(u.name) = UPPER(o.name)直接让索引作废
STRAIGHT_JOIN能强制顺序，但代价是放弃优化器判断
STRAIGHT_JOIN是MySQL唯一能绕过优化器重排JOIN顺序的手段，写在SELECT后立即生效，例如SELECT STRAIGHT_JOIN * FROM small_table s JOIN big_table b ON s.id = b.small_id。但它不是银弹。
使用前提很苛刻：
- 你必须确认左表经过WHERE过滤后确实很小（比如
rows - 一旦统计信息过期（比如没跑
ANALYZE TABLE），或者数据分布突变，STRAIGHT_JOIN反而比让优化器自己选更慢 - 它会禁用所有JOIN重排，包括多表场景下其他可能更优的组合路径
真正难的从来不是“怎么写STRAIGHT_JOIN”，而是你怎么确认那个“小结果集”在当前时刻、当前统计下，真的小——这需要定期验证EXPLAIN输出，而不是依赖某次测试结果。
