您的位置:首页 > 数据库 > MySQL

mysql在百万数据量下查询慢的问题

2015-11-25 10:44 369 查看
这两天,越来越觉得自己做的玩家历史表,查询速度很慢,开始还以为是网络的问题,然后持续了一两天很快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

总结一下,这次的确是有点疏忽大意了。乃至于出现如此慢的查询速度,同时也对于索引带来的效率感到欣慰,虽然索引在查询速度上有很大的提升,但是索引也不能随便用,因为每加一个索引,整个表的容量也会随之增加,因此合理利用以及因地制宜的利用索引才是王道。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: