Mysql必读分析MySQL中索引引引发的CPU负载飙升的问题

Mysql必读分析MySQL中索引引引发的CPU负载飙升的问题,第1张

概述介绍《Mysql必读分析MySQL中索引引引发的CPU负载飙升的问题》开发教程,希望对您有用。

《MysqL必读分析MysqL中索引引引发的cpu负载飙升的问题》要点:
本文介绍了MysqL必读分析MysqL中索引引引发的cpu负载飙升的问题,希望对您有用。如果有疑问,可以联系我们。

MysqL学习收到一个MysqL服务器负载告警,上去一看,load average都飙到280多了,用top一看,cpu跑到了336%,不过IO和内存的负载并不高,根据经验,应该又是一起索引引起的惨案了.

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

MysqL学习MysqL> explain SELECT count(1) FROM a,b WHERE a.ID = b.vIDeo_ID and b.state = 1 AND b.column_ID = '81'\G
MysqL学习*************************** 1. row ***************************ID: 1select_type: SIMPLEtable: btype: index_mergepossible_keys: columnID_vIDeoID,column_ID,state,vIDeo_time_stamp,IDx_vIDeoIDkey: column_ID,statekey_len: 4,4ref: NulLrows: 100Extra: Using intersect(column_ID,state); Using where*************************** 2. row ***************************ID: 1select_type: SIMPLEtable: atype: eq_refpossible_keys: PRIMARYkey: PRIMARYkey_len: 4ref: b.vIDeo_IDrows: 1Extra: Using where; Using index

MysqL学习再看下该表的索引情况:

MysqL学习MysqL> show index from b\G
MysqL学习*************************** 1. row ***************************table: bNon_unique: 0Key_name: PRIMARYSeq_in_index: 1Column_name: IDCollation: ACardinality: 167483Sub_part: NulLPacked: NulLNull:Index_type: BTREEComment:Index_comment:*************************** 2. row ***************************table: bNon_unique: 1Key_name: column_IDSeq_in_index: 1Column_name: column_IDCollation: ACardinality: 8374Sub_part: NulLPacked: NulLNull:Index_type: BTREEComment:Index_comment:*************************** 3. row ***************************table: bNon_unique: 1Key_name: stateSeq_in_index: 2Column_name: stateCollation: ACardinality: 5Sub_part: NulLPacked: NulLNull:Index_type: BTREEComment:Index_comment:

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

MysqL学习MysqL> show index from b;
MysqL学习*************************** 1. row ***************************table: bNon_unique: 0Key_name: PRIMARYSeq_in_index: 1Column_name: IDCollation: ACardinality: 128151Sub_part: NulLPacked: NulLNull:Index_type: BTREEComment:Index_comment:*************************** 2. row ***************************table: bNon_unique: 1Key_name: IDx_columnID_stateSeq_in_index: 1Column_name: column_IDCollation: ACardinality: 3203Sub_part: NulLPacked: NulLNull:Index_type: BTREEComment:Index_comment:*************************** 3. row ***************************table: bNon_unique: 1Key_name: IDx_columnID_stateSeq_in_index: 2Column_name: stateCollation: ACardinality: 3463Sub_part: NulLPacked: NulLNull:Index_type: BTREEComment: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: 1select_type: SIMPLEtable: btype: refpossible_keys: columnID_vIDeoID,IDx_vIDeoID,IDx_columnID_statekey: columnID_vIDeoIDkey_len: 4ref: constrows: 199Extra: Using where*************************** 2. row ***************************ID: 1select_type: SIMPLEtable: atype: eq_refpossible_keys: PRIMARYkey: PRIMARYkey_len: 4ref: b.vIDeo_IDrows: 1Extra: Using where; Using index

MysqL学习 可以看到执行计划变成了只用到了 IDx_columnID_state 索引,而且 ref 类型也变成了 const,sql执行耗时也从0.07s变成了0.00s,相应的cpu负载也从336%突降到了12%不到.

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

总结

以上是内存溢出为你收集整理的Mysql必读分析MySQL中索引引引发的CPU负载飙升的问题全部内容,希望文章能够帮你解决Mysql必读分析MySQL中索引引引发的CPU负载飙升的问题所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/1163356.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-06-01
下一篇 2022-06-01

发表评论

登录后才能评论

评论列表(0条)

保存