這篇文章主要介紹了分析MySQL中索引引引發的CPU負載飆升的問題,文中提到了獨立索引所帶來的巨大CPU負擔,以提醒在MySQL中使用索引要注意CPU負載的問題,需要的朋友可以參考下

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

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

1. 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. *************************** 1. row *************************** 
2. id: 1 
3. select_type: SIMPLE 
4. table: b 
5. type: index_merge 
6. possible_keys: columnid_videoid,column_id,state,video_time_stamp,idx_videoid 
7. key: column_id,state 
8. key_len: 4,4 
9. ref: NULL 
10. rows: 100 
11. Extra: Using intersect(column_id,state); Using where 
12. *************************** 2. row *************************** 
13. id: 1 
14. select_type: SIMPLE 
15. table: a 
16. type: eq_ref 
17. possible_keys: PRIMARY 
18. key: PRIMARY 
19. key_len: 4 
20. ref: b.video_id 
21. rows: 1 
22. Extra: Using where; Using index 

再看下該表的索引情況：

1. mysql> show index from b/G 

1. *************************** 1. row *************************** 
2. Table: b 
3. Non_unique: 0 
4. Key_name: PRIMARY 
5. Seq_in_index: 1 
6. Column_name: id 
7. Collation: A 
8. Cardinality: 167483 
9. Sub_part: NULL 
10. Packed: NULL 
11. Null: 
12. Index_type: BTREE 
13. Comment: 
14. Index_comment: 
15. *************************** 2. row *************************** 
16. Table: b 
17. Non_unique: 1 
18. Key_name: column_id 
19. Seq_in_index: 1 
20. Column_name: column_id 
21. Collation: A 
22. Cardinality: 8374 
23. Sub_part: NULL 
24. Packed: NULL 
25. Null: 
26. Index_type: BTREE 
27. Comment: 
28. Index_comment: 
29. *************************** 3. row *************************** 
30. Table: b 
31. Non_unique: 1 
32. Key_name: state 
33. Seq_in_index: 2 
34. Column_name: state 
35. Collation: A 
36. Cardinality: 5 
37. Sub_part: NULL 
38. Packed: NULL 
39. Null: 
40. Index_type: BTREE 
41. Comment: 
42. Index_comment: 

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

1. mysql> show index from b; 

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

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