这两天，越来越觉得自己做的玩家历史表，查询速度很慢，开始还以为是网络的问题，然后持续了一两天很快pass了这个想法。很可能是自己的查询速度慢，于是进入数据库看了一下，发现历史记录已经达到了600多万条了。随着dau的上升，玩家越来越多，乃至于历史记录也成倍的增长，虽然自己做了定时删除七天以前的记录，但还是承受不住巨量的人数增长带来的历史数据剧增。
因此，本人操作数据库直接测试了一下查询历史记录的sql语句，语句如下：
SELECT * FROM `history` WHERE `playerId`='1001' and `timestamp`>'2015-11-23 09:42' order BY `ID` DESC
结果用时达到了：3.47s，不相信这个时间，然后再次测试了几次，4.07s,3.55s,3.72s等等
同样的操作对玩家表进行了查询结果发现才0.04s，玩家表也有差不多百万条数据。但查询用时为何如此短呢?
于是自己从sql语句优化入手：
1.将上面的语句缩减到了：SELECT * FROM `history` WHERE `playerId`='1001' and `timestamp`>'2015-11-23 09:42'
去掉了排序，结果任然是3s多，
2.再次精简：SELECT * FROM `history` WHERE `playerId`='1001'
此时用时虽然降低了点，只用了2.7s左右，但是任然不如人意
3.最后突然想到了一点，自己之前是在玩家表做了索引的，而历史因为做了删除7天前的数据，并没有做索引。于是把playerid添加上索引再次用上面那句sql，结果果然如此，用时：0.004S
总结一下，这次的确是有点疏忽大意了。乃至于出现如此慢的查询速度，同时也对于索引带来的效率感到欣慰，虽然索引在查询速度上有很大的提升，但是索引也不能随便用，因为每加一个索引，整个表的容量也会随之增加，因此合理利用以及因地制宜的利用索引才是王道。