准线上事故之MySQL优化器索引选错( 三 ) _MySQL

3 解决思路当我们认为SQL的执行计划不合理时，可以使用explain 结合 trace工具去监听整个索引的使用、以及优化器进行优化的一些过程信息，如有必要，可以通过适当的手段去干预优化器。

最快的解决方式应该就是强制指定主键索引了，这种方式在我们需要快速解决线上问题的时候，还是很好用的。但是需要注意的是，强制指定索引是有一定风险的，如果哪天哪个小伙伴在不清楚这里的逻辑之下，修改了索引，极有可能会发生线上事故。
在MySQL的官方文档以及一些其他文章有特别说到，优化器的扫描行数，会随着表的数据新增、删除、字段变更等因素，统计的行数会变的不准确。这里可以考虑使用analyze table table_name 的方式去修复。需要注意的是，这个操作一般小伙伴是没有权限的，涉及线上操作。安全起见，如果需要验证，可以考虑把备份表down到本地去进行验证。
通过order by 、临时表、limit 等去干扰优化器。
设计合理的索引，编写合适的查询语句。MySQL：你这也太泛了

4 总结这篇文章是基于工作实际中碰到的问题，把问题产生的原因和解决思路总结了下。文中针对提到的一些索引选择差异情况我们结合了解到的优化器执行策略，使用trace工具进行了验证。优化器有一套非常复杂的算法策略，本人对于MySQL的理解深度有限，这里就不详细分析了，还需要继续学习。
另外了解到MySQL 8.0优化器对查询执行计划的选择做了进一步的改进，理想状态下，会基于估算成本选择最有效的执行计划。感兴趣的小伙伴可以去试试。