收到一个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 |
?
| 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: 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 |
再看下该表的索引情况：
?
| 1 | mysql> show index 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: |
可以看到执行计划中，使用的是index merge，效率自然没有用联合索引(也有的叫做覆盖索引)来的好了，而且 state 字段的基数（唯一性）太差，索引效果很差。删掉两个独立索引，修改成联合看看效果如何：
?
| 1 | mysql> show index 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> 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 |
可以看到执行计划变成了只用到了 idx_columnid_state 索引，而且 ref 类型也变成了 const，SQL执行耗时也从0.07s变成了0.00s，相应的CPU负载也从336%突降到了12%不到。
总结下，从多次历史经验来看，如果CPU负载持续很高，但内存和IO都还好的话，这种情况下，首先想到的一定是索引问题，十有八九错不了。
随时随地看视频
