驱动表应为EXPLAIN第一行；若本该过滤几十行的小表（如goods表WHERE tid=888）出现在第二行，而大表（如salebill 300万行）在第一行且key为NULL、rows高达280000，则优化器已误判小表为被驱动表。
直接看 explain 输出里哪一行的 type 是 all 或 index、rows 高达几十万以上，且它排在第二行或更后——这就是被错当成被驱动表的小表，优化器已经选错了。
怎么一眼确认驱动表真选错了
别信感觉，盯死三处：
-
EXPLAIN结果中，驱动表应是第一行；如果本该过滤出几十行的小表（比如goods表加了WHERE tid = 888）却出现在第二行，而大表（如salebill300 万行）在第一行且key为NULL，就是典型误判 - 小表那行的
rows值异常高（比如显示 280000），说明它没走索引、被当成了被驱动表去循环扫描 - 出现
Extra: Using join buffer (Block Nested Loop)，基本坐实：内层表太大，被迫缓存，根源就是驱动表不该这么大或没走索引
STRAIGHT_JOIN 写对了才生效
它不是“加了就稳”的开关，写错位置等于没写：
- 必须紧贴
SELECT后面，例如：SELECT STRAIGHT_JOIN u.name FROM users u JOIN orders o ON u.id = o.user_id；写成SELECT ... FROM users u STRAIGHT_JOIN orders o就无效 - 只作用于
FROM直接列出的表；套了子查询（如FROM (SELECT * FROM users) u）后，STRAIGHT_JOIN被完全忽略 - 顺序由
FROM中的表序决定：左边是驱动表，右边是被驱动表；ON条件、别名、WHERE位置都改不了这个顺序 - 不支持
UPDATE/DELETE，仅限SELECT
加了 STRAIGHT_JOIN 还慢？这些坑最常踩
语法没错，但逻辑冲突会让强制失效：
- 把没
WHERE条件的大表放左边当驱动表，比如STRAIGHT_JOIN orders o JOIN users u，而orders没任何过滤，直接扫千万行 - 驱动表加了
FORCE INDEX，但被驱动表的ON字段没索引（如user_id缺索引），照样全表扫描 - 字段类型或字符集不一致（
utf8mb4对utf8，DECIMAL对FLOAT），导致索引失效，STRAIGHT_JOIN白加 -
ON条件含函数，如ON DATE(o.create_time) = '2024-01-01'，被驱动表无法走索引，强制顺序也救不了
比 STRAIGHT_JOIN 更稳的长期解法
靠 STRAIGHT_JOIN 救火，本质是绕过优化器缺陷，隐患还在：
- 给被驱动表的
ON字段补索引，尤其高频关联字段（如user_id、goodsid）；联合索引列顺序尽量匹配ON条件顺序 - 把大表的过滤条件写进对应表的
WHERE子句，而不是堆在最后；例如WHERE a.tid = 888 AND a.billtype IN (5,6)要紧贴salebill a的定义逻辑 - 定期执行
ANALYZE TABLE更新统计信息（刚发布于 2026 年 6 月 1 日），让优化器有准确依据
真正难的不是加 STRAIGHT_JOIN，而是判断“为什么优化器会认为这张小表不该当驱动表”——往往是因为它上面的索引根本没生效，或者统计信息严重滞后。盯着 EXPLAIN 里的 key 和 rows 看，比盲目加 hint 有用得多。
