MYSQL分页limit速度太慢的优化方法

在mysql中limit可以实现快速分页，但是如果数据到了几百万时我们的limit必须优化才能有效的合理的实现分页了，否则可能卡死你的服务器

当一个表数据有几百万的数据的时候成了问题！

   如 select * from table limit 0,10 这个没有问题 当 limit 200000,10 的时候数据读取就很慢，可以按照一下方法解决
    第一页会很快

   PERCONA PERFORMANCE CONFERENCE 2009上，来自雅虎的几位工程师带来了一篇”EfficientPagination Using MySQL”的报告

  报告地址：https://www.open-open.com/pdf/2bda32bf64864e8e965e91686f5309d4.html

  有兴趣的朋友可以看下

   limit100000,20的意思扫描满足条件的100020行，扔掉前面的100000行，返回最后的20行，问题就在这里
   LIMIT 451350 , 30 扫描了45万多行，怪不得慢的都堵死了。

   但是
   limit 30 这样的语句仅仅扫描30行。

   那么如果我们之前记录了最大ID，就可以在这里做文章

直接上图，有图有真相，没有对比就没有伤害呀，请看下图

limit 100000

 

有没有一种过山车的感觉，贼刺激。

   举个例子

   日常分页SQL语句

SELECT
    id,
    title,
    ico,
    create_time,
    create_user
FROM
    article_copy1 
WHERE
 lm_id IN (3, 4, 5)
AND `status` = '1' 
ORDER BY
    id DESC
LIMIT 100000,10

   扫描100010行
   如果记录了上次的最大ID

SELECT
    id,
    title,
    ico,
    create_time,
    create_user
FROM
    article_copy1 
WHERE
 lm_id IN (3, 4, 5)
AND `status` = '1' and id < 2155652
ORDER BY
    id DESC
LIMIT 10;

   扫描10行。
   总数据有200万左右
   根据上面的列子 优化钱  执行时间是 50.024s
   优化后：

   行时间为 0.003s 速度明显提升

   请看下图

   这里需要说明的是  用到的字段（where条件中字段和order中字段）  一定记得 做复合索引，否则的话效果提升不明显

   总结

   当一个数据库表过于庞大，LIMIT offset, length中的offset值过大，则SQL查询语句会非常缓慢，你需增加order by，并且order by字段需要建立索引。
   如果使用子查询去优化LIMIT的话，则子查询必须是连续的，某种意义来讲，子查询不应该有where条件，where会过滤数据，使数据失去连续性。
   如果你查询的记录比较大，并且数据传输量比较大，比如包含了text类型的field，则可以通过建立子查询。

   SELECT id,title,content FROM items WHERE id IN (SELECT id FROM items ORDER BY id limit 900000, 10);

   如果limit语句的offset较大，你可以通过传递pk键值来减小offset = 0，这个主键最好是int类型并且auto_increment

   SELECT * FROM users WHERE uid > 456891 ORDER BY uid LIMIT 0, 10;