接收到MySQL服务器负载警报。一目了然，负载平均值已达到280以上。从顶部看，CPU运行到336%，但IO和内存的负载不高。根据经验，这应该是另一场由指数引起的大屠杀。

看看进程表和查询速度慢的情况，发现一个SQL经常出现。执行计划中扫描记录的数量仍然可用。一个单一的执行时间是0.07s，这是不是太大。乍一看，它可能不会造成的，但频率太高，执行计划看起来并不完美。


MySQL >解释select count（1）从B那里，张= b.video_id和b.state = 1





*************************** 1。行***************************
编号：1
select_type：简单
表：B
类型：index_merge
possible_keys：columnid_videoid，column_id，状态，video_time_stamp，idx_videoid
关键词：column_id，状态
key_len：4
参考：空
行数：100
额外的：使用相交（column_id，状态）；用在哪里
*************************** 2。行***************************
编号：1
select_type：简单
表：一
类型：eq_ref
possible_keys：初级
关键词：小学
key_len：4
参考：b.video_id
行数：1
附加：使用地点；使用索引




然后看看表格的索引。


从g显示索引





*************************** 1。行***************************
表：B
non_unique：0
key_name：初级
seq_in_index：1
column_name：ID
整理：一
基数：167483
sub_part：空
包装：空
无效的:
index_type：B树
评论：
index_comment：
*************************** 2。行***************************
表：B
non_unique：1
key_name：column_id
seq_in_index：1
column_name：column_id
整理：一
基数：8374
sub_part：空
包装：空
无效的:
index_type：B树
评论：
index_comment：
*************************** 3。行***************************
表：B
non_unique：1
key_name：状态
seq_in_index：2
column_name：状态
整理：一
基数：5
sub_part：空
包装：空
无效的:
index_type：B树
评论：
index_comment：




可以看出，在执行计划中，索引合并被使用，效率不足以使用联合索引（也称为覆盖索引），状态字段的基数（唯一性）太差，索引效果非常差。删除两个独立索引并修改它们以查看效果如何：


从b显示索引；





*************************** 1。行***************************
表：B
non_unique：0
key_name：初级
seq_in_index：1
column_name：ID
整理：一
基数：128151
sub_part：空
包装：空
无效的:
index_type：B树
评论：
index_comment：
*************************** 2。行***************************
表：B
non_unique：1
key_name：idx_columnid_state
seq_in_index：1
column_name：column_id
整理：一
基数：3203
sub_part：空
包装：空
无效的:
index_type：B树
评论：
index_comment：
*************************** 3。行***************************
表：B
non_unique：1
key_name：idx_columnid_state
seq_in_index：2
column_name：状态
整理：一
基数：3463
sub_part：空
包装：空
无效的:
index_type：B树
评论：
index_comment：

MySQL >解释select count（1）从B那里，张= b.video_id和b.state = 1

*************************** 1。行***************************
编号：1
select_type：简单
表：B
类型：裁判
possible_keys：columnid_videoid，idx_videoid，idx_columnid_state
关键词：columnid_videoid
key_len：4
参考：const
行数：199
附加：使用在哪里
*************************** 2。行***************************
编号：1
select_type：简单
表：一
类型：eq_ref
possible_keys：初级
关键词：小学
key_len：4
参考：b.video_id
行数：1
附加：使用地点；使用索引




你可以看到，执行计划改变了idx_columnid_state指数，和裁判也成为const类型。SQL语句的执行时间也从0.07s到0.00s，以及相应的CPU负载也从336%下降到不足12%。

总之，从很多历史经验来看，如果CPU负载很高，但内存和IO都是好的，首先要考虑的是索引问题。