mysql优化器选错索引主因是统计信息不准，analyze table通过重采样刷新cardinality等估算值可快速修复；force index仅临时生效但掩盖根本问题，稳定解法是将统计偏差纳入监控并定期干预。
MySQL优化器选错索引不是 bug，是它在统计信息不准、代价模型静态、数据分布突变时的合理误判；强制指定索引（FORCE INDEX）能临时止血，但掩盖了统计失真这个真正问题。
ANALYZE TABLE 为什么多数时候能立刻见效
优化器不看真实数据，只信 CARDINALITY 和 ROWS 这些采样估算值。当表经历大批量 DELETE + INSERT 后，旧统计严重偏离实际——比如 city_id = 565 实际只匹配 200 行，但统计显示“高频”，优化器就放弃 idx_city_id_type，转而扫 8000w 行。
ANALYZE TABLE 会重新随机采样约 10–20 个索引页（可由 innodb_stats_persistent_sample_pages 调整），刷新 information_schema.STATISTICS 中的关键字段。多数情况下，执行完慢查询就从秒级回落到毫秒级。
- 它不锁表太久，但会加 MDL 锁，大表需评估窗口期
- 仅对当前表生效，不会级联更新关联表统计
- 如果
innodb_stats_persistent = OFF，统计只存在内存里，重启即丢
FORCE INDEX 生效的前提和常见失效场景
FORCE INDEX 不是“加速开关”，它只在优化器本该用某索引却没用时起作用。例如 EXPLAIN 显示 type=ALL 或 key=NULL，而 WHERE 条件明显匹配一个已存在索引（如 WHERE created_at > '2025-01-01'，表上有 idx_created_at）。
但以下情况即使写了也无效：
- 联合索引
idx_a_b_c(a,b,c)，查询只写WHERE b = 1 AND c = 2→ 缺少最左列a，无法走索引 -
WHERE YEAR(created_at) = 2024→ 函数导致索引失效，强制指定也没用 -
user_id是INT，但传参是字符串'123'→ 隐式类型转换使索引失效 - 索引名写错，比如把
idx_user_status写成user_status（列名不是索引名）
FORCE INDEX 的语法细节和硬伤
它必须紧接在 FROM table_name 后面，括号不能省，索引名大小写敏感：
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); ✅（主键索引名固定为大写 <code>PRIMARY</code>）
多表 JOIN 中，每张表都要单独加：
... FROM orders o FORCE INDEX (idx_user_id) JOIN logs l FORCE INDEX (idx_device_id_ts) ON ...
它的硬伤很实在：
- 索引被
DROP INDEX或重命名后，SQL 立即报错：ERROR 1176 (HY000): Key 'xxx' doesn't exist in table 'yyy' - 数据量从 100 万涨到 1 亿后，原来高选择性的条件可能因分布倾斜变成低效扫描，但
FORCE INDEX仍死守 - 它绕过优化器决策，完全放弃自适应能力，一旦成本模型与现实脱节（比如 buffer pool 命中率突降），反而更慢
真正稳定的解法：把统计偏差当监控指标来管
统计不准这件事本身没有日志、不报错、不告警。它安静地拖垮性能，直到慢查询像雪崩一样涌进来。最危险的是你以为索引还在工作，其实优化器早已悄悄弃用。
根治思路不是“怎么强制用索引”，而是“怎么让优化器下次别再算错”：
- 把
ANALYZE TABLE加入运维巡检脚本，按表大小分级触发（小表每天，大表每周） - 监控
information_schema.STATISTICS.CARDINALITY波动趋势，偏差超过 30% 就自动触发重采样 - 对高频变更的大表，考虑开启
innodb_stats_persistent = ON并调高innodb_stats_persistent_sample_pages
复杂点在于：采样永远只是估算，而真实 I/O、buffer pool 命中率、当前系统负载这些变量，优化器根本看不到。所以“稳定”不是一劳永逸，是持续观测+及时干预。
