驱动表未走索引主因是其自身WHERE/ON条件未触发索引生效，而非JOIN顺序问题；需检查是否含函数、隐式转换、类型/字符集不一致、统计信息过期或索引未被覆盖等。
EXPLAIN 显示驱动表 type=ALL 或 key=NULL，但字段明明有索引
驱动表本身没走索引，通常不是“优化器选错了”，而是查询条件根本没触发索引生效。MySQL 不会因为表在 JOIN 中处于外层位置就自动用索引——它只看 WHERE、ON、ORDER BY 等子句能否利用现有索引。
- WHERE 条件用了函数或表达式，比如
WHERE DATE(create_time) = '2026-11-01'→ 改成WHERE create_time >= '2026-11-01' AND create_time - 字段类型不一致：驱动表
user_id是INT，但 ON 条件右边是VARCHAR，MySQL 会把整列转成浮点比较，索引直接失效 - 联合索引最左前缀没命中：索引是
(status, created_at)，但 WHERE 只写了created_at > ?，左边的status没出现，整个索引无法使用 - 字符集或排序规则不一致：比如一边是
utf8mb4_0900_as_cs，另一边是utf8mb4_general_ci，即使字段值完全相同，也无法走索引
STRAIGHT_JOIN 强制顺序后，驱动表还是全表扫描
加了 STRAIGHT_JOIN 只是锁定了连接顺序，并不保证驱动表能用索引。它解决的是“谁先查”，而不是“怎么查”。如果驱动表自身查询逻辑有问题，依然会扫全表。
- 检查该表对应的 EXPLAIN 行中
type和key：若type是ALL且key为NULL，说明驱动表的过滤条件没走索引 -
STRAIGHT_JOIN后再加FORCE INDEX才可能起效，例如：SELECT * FROM small_table FORCE INDEX (idx_status) STRAIGHT_JOIN big_table ON ... - 注意：如果驱动表本身数据量极小（比如几十行），优化器可能认为全表扫描比走索引还快，这时
type=ALL是合理行为，不是 bug
驱动表有索引，但 rows 预估严重不准
EXPLAIN 里的 rows 值不准，会导致优化器误判“这个表其实很小”，从而放弃走索引——哪怕你肉眼可见它有百万行。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 运行
ANALYZE TABLE table_name更新统计信息，特别是大批量 INSERT/DELETE 后必须做 - 查看
SHOW INDEX FROM table_name中Cardinality是否明显偏低（如为 0 或远小于实际行数） - 某些场景下，直方图统计比默认采样更准：MySQL 8.0+ 可用
ANALYZE TABLE table_name UPDATE HISTOGRAM ON col1, col2 - 预估不准常伴随
STRAIGHT_JOIN失效：你以为强制了顺序，但优化器发现“咦？这表预估才 10 行”，结果真按全表扫了
为什么 LIMIT 不让驱动表走索引？
LIMIT 对驱动表是否走索引**完全无影响**。优化器基于预估扫描行数决策，不是基于最终返回几行。你在 SELECT 后加 LIMIT 10，不会让原本 type=ALL 的驱动表变成 ref。
- 常见误解：以为 “加 LIMIT 就能提前终止”，但 MySQL 必须先定位到满足 WHERE 的所有行，才能取前 N 行；索引是否启用，取决于 WHERE 怎么写
- 真正能减少扫描的，是让 WHERE 条件本身更精准，比如把
WHERE status IN ('a','b','c')改成WHERE status = 'a'（如果业务允许） - 如果驱动表必须返回大量中间结果，又受限于内存，
join_buffer_size不够也可能导致退化为 BNL，但这属于被驱动表侧问题，不影响驱动表索引选择
复杂点在于：驱动表索引是否生效，和 JOIN 关系不大，本质还是单表查询优化问题。很多人盯着 ON 条件调索引，却忘了驱动表自己的 WHERE 才是第一道门槛。
