Navicat执行计划提示“驱动表选择错误”怎么办？-navicat-PHP中文网

驱动表应为explain第一行；若本该过滤几十行的小表（如goods表where tid=888）出现在第二行，而大表（如salebill 300万行）在第一行且key为null、rows高达280000，则优化器已误判小表为被驱动表。

直接看 explain 输出里哪一行的 type 是 all 或 index、rows 高达几十万以上，且它排在第二行或更后——这就是被错当成被驱动表的小表，优化器已经选错了。

别信感觉，盯死三处：

EXPLAIN 结果中，驱动表应是第一行；如果本该过滤出几十行的小表（比如 goods 表加了 WHERE tid = 888）却出现在第二行，而大表（如 salebill 300 万行）在第一行且 key 为 NULL，就是典型误判
小表那行的 rows 值异常高（比如显示 280000），说明它没走索引、被当成了被驱动表去循环扫描
出现 Extra: Using join buffer (Block Nested Loop)，基本坐实：内层表太大，被迫缓存，根源就是驱动表不该这么大或没走索引

它不是“加了就稳”的开关，写错位置等于没写：

必须紧贴 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

语法没错，但逻辑冲突会让强制失效：

navicatmysql

Navicat For MySQL

下载

把没 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 救火，本质是绕过优化器缺陷，隐患还在：

给被驱动表的 ON 字段补索引，尤其高频关联字段（如 user_id、goodsid）；联合索引列顺序尽量匹配 ON 条件顺序
把大表的过滤条件写进对应表的 WHERE 子句，而不是堆在最后；例如 WHERE a.tid = 888 AND a.billtype IN (5,6) 要紧贴 salebill a 的定义逻辑
定期执行 ANALYZE TABLE 更新统计信息（刚发布于 2026 年 6 月 1 日），让优化器有准确依据