剖析MySQL中索引引激發的CPU負載飙升的成績。本站提示廣大學習愛好者：（剖析MySQL中索引引激發的CPU負載飙升的成績）文章只能為提供參考，不一定能成為您想要的結果。以下是剖析MySQL中索引引激發的CPU負載飙升的成績正文
收到一個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都還好的話，這類情形下，起首想到的必定是索引成績，十有八九錯不了。
