分析MySQL中索引引引发的CPU负载飙升的问题
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了分析MySQL中索引引引发的CPU负载飙升的问题，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含3882字，纯文字阅读大概需要6分钟。
内容图文
收到一个mysql服务器负载告警，上去一看，load average都飙到280多了，用top一看，CPU跑到了336%，不过IO和内存的负载并不高，根据经验，应该又是一起索引引起的惨案了。
看下processlist以及slow query情况，发现有一个SQL经常出现，执行计划中的扫描记录数看着还可以，单次执行耗时为0.07s，还不算太大。乍一看，可能不是它引发的，但出现频率实在太高，而且执行计划看起来也不够完美：
mysql> explain SELECT count(1) FROM a , b WHERE a.id = b.video_id and b.state = 1 AND b.column_id = '81'\G
*************************** 1. row *************************** id: 1 select_type: SIMPLE table: b type: index_merge possible_keys: columnid_videoid,column_id,state,video_time_stamp,idx_videoid key: column_id,state key_len: 4,4 ref: NULL rows: 100 Extra: Using intersect(column_id,state); Using where *************************** 2. row *************************** id: 1 select_type: SIMPLE table: a type: eq_ref possible_keys: PRIMARY key: PRIMARY key_len: 4 ref: b.video_id rows: 1 Extra: Using where; Using index
再看下该表的索引情况：
mysql> show index from b\G
*************************** 1. row *************************** Table: b Non_unique: 0 Key_name: PRIMARY Seq_in_index: 1 Column_name: id Collation: A Cardinality: 167483 Sub_part: NULL Packed: NULL Null: Index_type: BTREE Comment: Index_comment: *************************** 2. row *************************** Table: b Non_unique: 1 Key_name: column_id Seq_in_index: 1 Column_name: column_id Collation: A Cardinality: 8374 Sub_part: NULL Packed: NULL Null: Index_type: BTREE Comment: Index_comment: *************************** 3. row *************************** Table: b Non_unique: 1 Key_name: state Seq_in_index: 2 Column_name: state Collation: A Cardinality: 5 Sub_part: NULL Packed: NULL Null: Index_type: BTREE Comment: Index_comment:
可以看到执行计划中，使用的是index merge，效率自然没有用联合索引(也有的叫做覆盖索引)来的好了，而且 state 字段的基数（唯一性）太差，索引效果很差。删掉两个独立索引，修改成联合看看效果如何：
mysql> show index from b;
*************************** 1. row *************************** Table: b Non_unique: 0 Key_name: PRIMARY Seq_in_index: 1 Column_name: id Collation: A Cardinality: 128151 Sub_part: NULL Packed: NULL Null: Index_type: BTREE Comment: Index_comment: *************************** 2. row *************************** Table: b Non_unique: 1 Key_name: idx_columnid_state Seq_in_index: 1 Column_name: column_id Collation: A Cardinality: 3203 Sub_part: NULL Packed: NULL Null: Index_type: BTREE Comment: Index_comment: *************************** 3. row *************************** Table: b Non_unique: 1 Key_name: idx_columnid_state Seq_in_index: 2 Column_name: state Collation: A Cardinality: 3463 Sub_part: NULL Packed: NULL Null: Index_type: BTREE Comment: Index_comment: mysql> explain SELECT count(1) FROM a , b WHERE a.id = b.video_id and b.state = 1 AND b.column_id = '81' \G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: b type: ref possible_keys: columnid_videoid,idx_videoid,idx_columnid_state key: columnid_videoid key_len: 4 ref: const rows: 199 Extra: Using where *************************** 2. row *************************** id: 1 select_type: SIMPLE table: a type: eq_ref possible_keys: PRIMARY key: PRIMARY key_len: 4 ref: b.video_id rows: 1 Extra: Using where; Using index
可以看到执行计划变成了只用到了 idx_columnid_state 索引，而且 ref 类型也变成了 const，SQL执行耗时也从0.07s变成了0.00s，相应的CPU负载也从336%突降到了12%不到。
总结下，从多次历史经验来看，如果CPU负载持续很高，但内存和IO都还好的话，这种情况下，首先想到的一定是索引问题，十有八九错不了。
您可能感兴趣的文章:
- 简单介绍下MYSQL的索引类型
- 探究MySQL优化器对索引和JOIN顺序的选择
- 简单介绍MySQL中索引的使用方法
- MySQL索引优化的实际案例分析
- mysql索引失效的五种情况分析
- MySQL索引操作命令小结
- 什么情况下需要创建MySQL索引？
- mysql 中存在null和空时创建唯一索引的方法
- Mysql索引详细介绍
- MySQL查看、创建和删除索引的方法
内容总结
以上是互联网集市为您收集整理的分析MySQL中索引引引发的CPU负载飙升的问题全部内容，希望文章能够帮你解决分析MySQL中索引引引发的CPU负载飙升的问题所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。