如何进行索引调优？

提示

题眼： 从索引失效，慢查询，Explan三个角度展开。

索引调优

• 分析查询语句和数据模式：仔细分析查询语句和数据模式，了解查询的特点和使用频率，确保索引的创建和选择符合实际需求。
• 选择合适的索引策略：根据查询的特点选择合适的索引策略，包括覆盖索引、联合索引、前缀索引等，以提高查询性能。
• 优化查询语句：优化查询语句的结构和条件，避免使用不适合索引的操作符或函数操作，尽量使查询条件能够命中索引。
• 避免过度索引：避免创建过多的索引，因为过多的索引会增加数据维护的开销，并可能导致索引失效或选择不正确的索引。
• 使用索引提示：在需要的情况下，使用索引提示（Index Hint）来强制MySQL使用指定的索引，以避免错误的索引选择。
• 性能测试和监测：通过性能测试和监测工具，如EXPLAIN、 Slow Query Log等，评估索引的效果，并进行必要的调整和优化

重要

参考答案：

我在工作中遇到的索引调优一般是两种情况，第一种是原数据表没有索引，或者索引设计的不太合理需要优化。另一种，是出现了慢查询的情况。

针对第一种情况，其实还算是比较好处理。因为业务上使用的SQL语句都比较简单，都是一些基础的SELECT，最多也就是查询条件复杂点。我们会根据日常中使用频率最高的一些场景，设计一个联合索引，尽可能把常用字段放进去，这样可以减少回表。然后，对于比较复杂、比较低频的业务场景，会尽量把他的SQL语句拆开，然后能走索引就走索引，最后把查询出来的数据放到缓存里，这样就可以提高查询效率。还有一些比较棘手的SQL，会使用EXPLAIN分析下SQL执行的情况，有没有走索引，扫了多少数据，有没有回表这些，来决定是单独建一个索引还是优化业务场景。毕竟MySQL去维护一个索引也是要开销额度嘛。

第二种情况，我认为还是很有挑战性的，工作中也遇到过几次。比如有一次群里有慢查询的告警，然后我去排查下来是后台管理员设置了一个很复杂的筛选条件，查询一些历史数据，像这种场景比较难处理。因为出现的频率不高，而且都是一些历史数据，但是这个慢查询的危害很大，因为这个SQL执行了好久，堵塞了后续其他SQL的执行，导致接口出现了超时的情况。我们最后的处理方法是，给主表加了一个超时时间，然后把这个业务场景的SQL都挪到备机去执行，这样子不会阻塞主库的操作。