背景与问题在生产环境中收到一个接口耗时预警, 通过监控发现, 接口耗时达到了89s, 最终定位到了是因为触发了一个sql慢查询场景....故可以断定mysql底层在选择索引的时候, 是一个动态调整的过程, 会基于数据分布情况进行动态选择(可能是最合适的也可能选择了很差性能的索引)3.3 尝试3 - 避免排序将排序字段去除, 也是可以避免慢查询...去除fpar_name的单字段索引即删除误用的低效索引, 避免mysql引擎自动选择到它, 不给其机会, 并且该字段的索引效率低其实也没有必要加(fpar_name的区分度仅为0.0002), 因为索引字段应该区分度足够高才真正有效...而优化器选择索引的目的,是找到一个最优的执行方案,并用最小的代价去执行sql。扫描行数是影响执行代价的因素之一, 扫描的行数越少,说明访问磁盘数据的次数越少,CPU消耗越少....本文通过线上生产环境遇到的一个实际问题, 引出本文重点-mysql索引选择原理探究, 并对问题进行详细的分析和探索, 然后给出了多种解决思路和方案, 助力开发者深度掌握mysql底层索引选择机制并付诸实践