分析MySQL中索引引引发的CPU负载飙升的问题(mysql索引类型及原理)

编辑：rootadmin

推荐整理分享分析MySQL中索引引引发的CPU负载飙升的问题(mysql索引类型及原理)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:mysql索引方式有哪些,mysql索引的理解,mysql 索引分析,mysql中的索引,mysql各种索引的使用场景,mysql各种索引的使用场景,mysql 索引分析,mysql索引的使用和原理,内容如对您有帮助，希望把文章链接给更多的朋友！

收到一个mysql服务器负载告警，上去一看，load average都飙到多了，用top一看，CPU跑到了%，不过IO和内存的负载并不高，根据经验，应该又是一起索引引起的惨案了。

看下processlist以及slow query情况，发现有一个SQL经常出现，执行计划中的扫描记录数看着还可以，单次执行耗时为0.s，还不算太大。乍一看，可能不是它引发的，但出现频率实在太高，而且执行计划看起来也不够完美：

再看下该表的索引情况：

可以看到执行计划中，使用的是index merge，效率自然没有用联合索引(也有的叫做覆盖索引)来的好了，而且 state 字段的基数（唯一性）太差，索引效果很差。删掉两个独立索引，修改成联合看看效果如何：

可以看到执行计划变成了只用到了 idx_columnid_state 索引，而且 ref 类型也变成了 const，SQL执行耗时也从0.s变成了0.s，相应的CPU负载也从%突降到了%不到。

总结下，从多次历史经验来看，如果CPU负载持续很高，但内存和IO都还好的话，这种情况下，首先想到的一定是索引问题，十有八九错不了。

MySQL索引优化的实际案例分析 Orderbydesc/asclimitM是我在mysqlsql优化中经常遇到的一种场景，其优化原理也非常的简单，就是利用索引的有序性，优化器沿着索引的顺序扫描，在扫描到符

浅谈MySQL中的子查询优化技巧 mysql的子查询的优化一直不是很友好，一直有受业界批评比较多,也是我在sql优化中遇到过最多的问题之一，你可以点击这里，这里来获得一些信息，mysql

MySQL的id关联和索引使用的实际优化案例昨晚收到客服MM电话，一用户反馈数据库响应非常慢，手机收到load异常报警，登上主机后发现大量sql执行非常慢，有的执行时间超过了s优化点一：SELEC

本文链接地址:https://www.jiuchutong.com/biancheng/347323.html 转载请保留说明！