通常情况下我们都这样这样取分页数据
SELECT * FROM ol_answerlog ORDER BY AnswerLogId LIMIT 10000,10
一般情况下,ORM生成的就是这种语句。
无论排序字段有没有索引都有严重的性能问题,因为高偏移量会让服务器花费更多的时间来扫描被丢掉的数据。
非规范化、预先计算、或缓存可能是解决这类查询的唯一办法,一个更好的策略是限制让用户查看的页数,这样并影响用户的体验,因为没有人会真正在意搜索结果的第10000页,另外一个优化这种查询的好策略就是只提取最终需要的主键列,然后把它再连接回去以取得所有需要的列,这有助于优化mysql必须进行的收集最终会丢掉的数据工作。
这样会让服务器扫描很多需要丢掉的数据。
可以这样:
先取出主键数据,再取出需要列的数据
SELECT * FROM ol_answerlog g INNER JOIN (
SELECT AnswerLogId FROM ol_answerlog ORDER BY AnswerLogId LIMIT 100000,10)
AS tt
ON g.AnswerLogId = tt.AnswerLogId
实例测试
ol_answerlog 表 2000万数据
一、通常做法
SELECT SQL_NO_CACHE * FROM ol_answerlog ORDER BY AnswerLogId LIMIT 100000,10
需要约400ms
二、优化分页
SELECT SQL_NO_CACHE
* FROM ol_answerlog g INNER JOIN (
SELECT AnswerLogId FROM ol_answerlog ORDER BY AnswerLogId LIMIT 100000,10)
AS tt
ON g.AnswerLogId = tt.AnswerLogId
用时40ms
| 通常做法 SELECT SQL_NO_CACHE * FROM ol_answerlog ORDER BY AnswerLogId LIMIT m,10 | 优化分页 SELECT SQL_NO_CACHE * FROM ol_answerlog g INNER JOIN ( |
10000 | 40ms | <10ms |
100000 | 400ms | 40ms |
1000000 | 4s | 400ms |
10000000 | 46s | <4s |
原文: http://www.cnblogs.com/cocos/archive/2010/11/25/1888040.html