今天上班发现线上机器CPU告警，看了一下发现是mysqld一直占用CPU处于满负荷状态，show processlist;一下，发现很多查询在排序状态，随便拿了一条sql explain看了一下，如下图：
注意到后面多了一个Using filesort; 这个的意思并不是说要在磁盘上进行排序。因为mysql的排序方法主要分为两大类，一种是排序的字段是有索引的，因为索引是有序的，所以不需要另外排序，另一种是排序的字段没有索引，所以需要对结果进行排序，在这种情况下才会如上图所示显示一个Using filesort表示这个查询需要排序。而这里奇怪的是，这个查询的排序字段applydate是有索引的，而且看possible_keys这一栏也可以看到这个索引在检索的时候是可能用到的key。
Show index 确认是否有索引：
问题查到这里开始有点不知所措了，内存问题也被排除了。然后考虑是否是max_length_for_sort_data, sort_buffer_size这个参数设置过小造成的，实际上后来想想这个因素是可以直接排除的，因为如果索引可以用的话是不需要另外排序的。开始怀疑是否是索引不可用的问题了。于是冒险把索引重建了试试。一开始尝试能不能用repair命令来修复索引，发现这个命令只适用于myisam引擎，于是只好删除索引重建。160W+行，删除一个索引耗时14min, 创建索引耗时19min，当然这个耗时不是绝对的，还要考虑机器CPU性能、负荷情况、以及各参数设置等。
在删除掉了索引还没创建之前，我特地测试了一下同一条查询在有老的索引和当前没有这个关键索引的情况下的查询时间，删除索引前耗时13s，删除索引后耗时19s，可以说是在同一个量级了，到这里似乎更能确定索引其实是不可用的。
等待19min后，重建索引成功，迫不及待的试着执行了同一条sql，耗时0.22s。瞬间那个激动的心情溢于言表。再次explain这条查询，Using filesort也没有了。至此问题算是解决了。但是疑惑还是有很多，主要有以下几点：
1.是什么导致了索引不可用
2.如何确定执行执行这条查询的时候实际上是否用到了索引(explain的参数都是预估的)，能否实时看到sql执行的情况。
对于第一个问题，看来还需要大量的学习，虽然知道索引是B+树实现的，自己也能手写一个B树出来，但是mysql究竟是如何通过这个B树来加快查询还是不太明白。对于第二个问题，打算研究一下mysql内核，看看能否找到问题的答案。
