MySQL未自动选用性能更优的索引B，无法用FORCE INDEX，求原因

嗨，这个问题在日常SQL优化里真的挺常见的——明明手动强制用索引B快了好几倍，MySQL优化器却偏偏死磕索引A。下面几个核心原因能帮你搞懂它的“脑回路”：

• 统计信息过时，优化器拿了旧情报
  MySQL的查询优化器完全依赖表和索引的统计数据来计算成本。如果你刚创建了索引B，但没更新统计信息，优化器可能还停留在“索引A的数据分布更优”的旧认知里。这时候跑一下ANALYZE TABLE your_table;，让优化器重新获取最新的索引基数、数据分布情况，大概率会纠正它的选择。

• 优化器的成本估算模型和实际情况有偏差
  优化器会计算IO成本、CPU成本来判断用哪个索引更划算，但它的估算模型不是万能的：

  • 比如索引B是覆盖索引（包含查询所需的所有字段，不需要回表），但优化器没准确计算回表带来的额外开销；
  • 或者你的数据有严重倾斜（比如某个字段的少数值占了大部分数据），统计信息里的平均分布估算和实际不符，导致优化器觉得用索引A的成本更低。

• 对查询返回行数的判断失误
  如果优化器估算你的查询会返回表中很高比例的数据（比如超过20%），它可能会觉得“用索引还不如全表扫/用更宽的索引A”，但实际你的查询返回的行数远低于这个比例。这种情况下，优化器的判断就和实际性能脱节了。

• 执行计划缓存“偷懒”
  如果你之前多次执行过这条查询，MySQL可能缓存了旧的执行计划（用索引A的那个），即使你建了新索引B，它也没重新评估。可以试试FLUSH TABLES your_table;清除相关缓存，让优化器重新生成执行计划。

框架不能用FORCE INDEX？试试这些替代方案： #

1. 先更新统计信息：优先跑ANALYZE TABLE your_table;，这是最省心的修复方式；
2. 调整索引结构：如果索引B是联合索引，试试调整字段顺序，让它更贴合查询的过滤条件，优化器更容易识别它的价值；
3. 精简查询字段：如果框架生成的是SELECT *，改成明确查询需要的字段——如果索引B刚好是覆盖索引，优化器会立刻意识到它能避免回表，自然会优先选它；
4. 移除冗余索引A：如果索引A已经没有其他查询在使用，直接删掉它，优化器就没得选了（谨慎操作，先确认索引A的使用情况）。

内容的提问来源于stack exchange，提问作者Yannick Richard