收到一個mysql服務(wù)器負(fù)載告警，上去一看，load average都飆到280多了，用top一看，CPU跑到了336%，不過IO和內(nèi)存的負(fù)載并不高，根據(jù)經(jīng)驗，應(yīng)該又是一起索引引起的慘案了。

看下processlist以及slow query情況，發(fā)現(xiàn)有一個SQL經(jīng)常出現(xiàn)，執(zhí)行計劃中的掃描記錄數(shù)看著還可以，單次執(zhí)行耗時為0.07s，還不算太大。乍一看，可能不是它引發(fā)的，但出現(xiàn)頻率實在太高，而且執(zhí)行計劃看起來也不夠完美：

?1mysql> explainSELECT count(1)FROM a , bWHERE a.id = b.video_idand b.state = 1AND b.column_id ='81'\G

?12345678910111213141516171819202122*************************** 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: Usingintersect(column_id,state); Usingwhere*************************** 2. row ***************************id: 1select_type: SIMPLEtable: atype: eq_refpossible_keys:PRIMARYkey:PRIMARYkey_len: 4ref: b.video_idrows: 1Extra: Usingwhere; Usingindex

再看下該表的索引情況：

?1mysql> showindex from b\G

?123456789101112131415161718192021222324252627282930313233343536373839404142*************************** 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:

可以看到執(zhí)行計劃中，使用的是index merge，效率自然沒有用聯(lián)合索引(也有的叫做覆蓋索引)來的好了，而且 state 字段的基數(shù)(唯一性)太差，索引效果很差。刪掉兩個獨(dú)立索引，修改成聯(lián)合看看效果如何：

?1mysql> showindex from b;

?12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667*************************** 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> explainSELECT count(1)FROM a , bWHERE a.id = b.video_idand b.state = 1AND 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: Usingwhere*************************** 2. row ***************************id: 1select_type: SIMPLEtable: atype: eq_refpossible_keys:PRIMARYkey:PRIMARYkey_len: 4ref: b.video_idrows: 1Extra: Usingwhere; Usingindex

可以看到執(zhí)行計劃變成了只用到了 idx_columnid_state 索引，而且 ref 類型也變成了 const，SQL執(zhí)行耗時也從0.07s變成了0.00s，相應(yīng)的CPU負(fù)載也從336%突降到了12%不到。

總結(jié)下，從多次歷史經(jīng)驗來看，如果CPU負(fù)載持續(xù)很高，但內(nèi)存和IO都還好的話，這種情況下，首先想到的一定是索引問題，十有八九錯不了。

總結(jié)

以上是生活随笔為你收集整理的mysql写入 cpu飙升_分析MySQL中索引引引发的CPU负载飙升的问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。