如果数据够大,翻页的时候,翻页量越大,耗时越长,例如:

大数据量分页优化_大数据量

大数据量分页优化_分页优化_02

大数据量分页优化_分页优化_03


解决办法:

  1. 从业务上优化。谷歌、百度等只显示前几十页

  2. 不能省,就只能性能上优化了


为什么limit offset在数据量很大的情况下效率很低?

用limit offset时并不是先跳过再查询,而是先查询再跳过。

例如:limit 100w, 10:

就是先把100w取出来,再跳过前100w行。

show profiles:

大数据量分页优化_大数据量_04

show profile for query 115:

大数据量分页优化_大数据量_05

(很显然,在Sending data花的时间最多)


但以id作为where条件来查询,则很快。毕竟id是主键:

大数据量分页优化_大数据量_06

但是上面,只能针对连续的id。其实还可以取出最后一个id,记住它,下次翻页就从当前id开始

当然也可以逻辑删除,只是代码做个处理,不让它显示出来就行。

如果非要进行物理删除,还可以延迟关联

大数据量分页优化_分页优化_07

上面取主键,还要取name(回行),所以花费的时间会很长

但好在id在(myisam引擎下)内存里存着的,速度会比较快

大数据量分页优化_分页优化_08

大数据量分页优化_大数据量_09

做个join查询:

大数据量分页优化_分页优化_10

上面跳过巨多行数据的查询竟然用join,而且速度还可以。

因为这次不是不断回行了,而是先找好id,再在磁盘上查找name