为什么MySQL执行计划有时会选错索引该如何强制纠正-mysql教程-PHP中文网

确认优化器选错索引需比对三组数字：rows预估扫描行数与实际COUNT(*)结果偏差是否超30%，filtered值是否极低（如

为什么mysql执行计划有时会选错索引该如何强制纠正

MySQL 选错索引不是 bug，是优化器基于过期/失真统计信息做的“合理误判”；强制纠正不能只靠 FORCE INDEX 硬上，得先确认它真错了、再选对干预方式。

怎么确认优化器真选错了索引

别光看 EXPLAIN 的 key 列，重点比三组数字：

rows（预估扫描行数）和你手动 SELECT COUNT(*) WHERE ... 的实际结果偏差是否超过 30%？偏差大说明统计失真
filtered 值是否极低（比如
是否存在 Using filesort 或 Using temporary？结合 ORDER BY 和 LIMIT 时，优化器可能为避免排序而弃用更优索引（如 order by id limit 强制走主键却扫全表）

如果 EXPLAIN FORMAT=JSON 显示 used_range_access 为 false，且 rows_examined_per_scan 远高于实际命中行数，基本可断定选错。

`FORCE INDEX` 的写法和致命陷阱

语法必须严格：FORCE INDEX 要紧贴 FROM 表名后，不能塞到 WHERE 后面，也不能写错索引名——主键索引名固定是 PRIMARY（大写）。

✅ 正确：SELECT * FROM orders FORCE INDEX (idx_user_status) WHERE user_id = 123;
❌ 错误：SELECT * FROM orders WHERE user_id = 123 FORCE INDEX (idx_user_status);（解析失败）
❌ 错误：SELECT * FROM orders FORCE INDEX (primary) WHERE ...（大小写敏感，报错 ERROR 1176）

硬编码索引名会埋雷：后续删索引、改名、或某 user_id 数据量暴涨十倍，FORCE 反而让查询更慢，且无任何告警。

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

比 `FORCE INDEX` 更稳的修复路径

优先用 ANALYZE TABLE 刷新统计信息，它直接修正优化器的“决策依据”：

对大表或刚批量导入数据后，ANALYZE TABLE orders 通常立竿见影
检查 information_schema.STATISTICS 中 CARDINALITY 是否明显失真（如 status 只有 3 个值，但显示基数为 10000）
生产环境避开高峰期执行；MySQL 8.0+ 默认轻量采样，5.7 及以前版本可能锁表

若 ANALYZE 无效，再查是否触发了隐式类型转换（如 WHERE user_id = '123' 但字段是 INT）或函数包裹（如 WHERE DATE(created_at) = ...）——这些情况下索引本就不能用，FORCE 也救不了。