S
soul
Unregistered / Unconfirmed
GUEST, unregistred user!
长久以来，大富翁的翻页始终很累，我亦非常之痛苦。
于是有各种思路盘旋在我心中，核心的想法就是如何直接定位一个页第一个记录。
于是有yysun弄出3个存储过程，一举使得大富翁得到了第一次提速，可以数据库太大了，
终于还是越来越慢，特别翻页到大号码的时候，出现的只是空白。
究竟是什么因素导致了大富翁如此之慢呢？
我终于开始研习查询分析器，仔细学习如何优化查询，结果发现，大富翁代码中很多语句
有类似select * from letters where parent=0 and status<2 order by datetime desc
的句法，而差sql在查询计划中有是一个占有绝大多数时间的where，也就是只能一个一个
匹配，而不能直接seek，那么一定问题出在索引上，经过仔细思考，加上了索引
(parent,datetime,status)这么一个索引，在查看查询计划，发现变成了scan，seek，
执行之，哇，本来2000ms一下子变成了50ms，吾不禁狂喜。
当然这只是优化的一部分，存储过程中一些关键sql我也更换成了更高效的语句，效果
非常只好。
原来不用改代码，只要加加索引，修改一下sql就可以成百上千倍的增加性能啊。
于是有各种思路盘旋在我心中，核心的想法就是如何直接定位一个页第一个记录。
于是有yysun弄出3个存储过程，一举使得大富翁得到了第一次提速，可以数据库太大了，
终于还是越来越慢，特别翻页到大号码的时候，出现的只是空白。
究竟是什么因素导致了大富翁如此之慢呢？
我终于开始研习查询分析器，仔细学习如何优化查询，结果发现，大富翁代码中很多语句
有类似select * from letters where parent=0 and status<2 order by datetime desc
的句法，而差sql在查询计划中有是一个占有绝大多数时间的where，也就是只能一个一个
匹配，而不能直接seek，那么一定问题出在索引上，经过仔细思考，加上了索引
(parent,datetime,status)这么一个索引，在查看查询计划，发现变成了scan，seek，
执行之，哇，本来2000ms一下子变成了50ms，吾不禁狂喜。
当然这只是优化的一部分，存储过程中一些关键sql我也更换成了更高效的语句，效果
非常只好。
原来不用改代码，只要加加索引，修改一下sql就可以成百上千倍的增加性能啊。
]