limit简要分析

limit分析：

查询分页，limit [offset] rows ,offset 是偏移量，rows是需要的数据行数，当偏移量较大时，就会发现limit是从头开始查询到offset+rows，然后舍弃前面的行数返回最后的rows行，这样在小量数据是没有太大问题的，但是在百万或者千万级的数据表中进行查询就会非常吃力，

从上面表可以看出，效率极差，即使经过优化，比如加上 “order by id”，使用主键索引进行查询优化，经过测试表明，当偏移量较大时也是很慢，所以进来避免在2000000以上的数据表中使用。反向查找的结果是是降序desc的，并且InputDate是记录的插入时间，也可以用主键联合索引，但是不方便。

limit推荐优化1：

SELECT * FROM t_limitgate3 WHERE id >=(select id from t_limitgate3 limit 9000000, 1) limit 100

使用该语句对：

select * from t_limitgate3 limit 9000000,100

进行优化对比

由第九百万行开始一百条	使用优化前	使用优化后
第一次执行	1:00	14.976s
第二次执行	1:00	7.332s

1钟与14秒的差距还是很大的嘛，真的快了很多~~差不多快了4倍，

第二次执行，只用了短短的7.332s

优化前的语句第二次执行，依然是1分钟，第二次执行测试快了相当于8倍左右，相当可以了呢！

limit推荐优化2：

SELECT * FROM t_limitgate3 a JOIN (select id from t_limitgate3 limit 9000000, 100) b ON a.id = b.id

使用该语句对：

select * from t_limitgate3 limit 9000000,100

进行优化对比

由第九百万行开始一百条	使用优化前	使用优化后
第一次执行	1:00	15.741s
第二次执行	1:00	16.209s

1钟与15秒的差距也还是很大的，同样快了很多~~差不多也是快了4倍，

第二次执行，用了短短的16.209s

优化前的语句第二次执行，依然还是1分钟，第二次执行测试快了相当于4左右，也同样相当可以了呢！

总结:

总的来说limit分页查询还是不错的，虽然普通的未经优化的limit使用不尽人意，但是经过优化过后的确是很好用！千万级数据也是很快的。当然这是根据业务分析的话，一般一个页面展示100条记录也已经差不多！ 最后根据各种测试使用，limit优化过得查询语句在数据行数超过5000条以上的数据也很慢，尝试两种优化查询5000条数据均耗时17s左右，由此看来limit只是适合任意偏移量，少量行数的情况，大量的行数查询也是不可行的。

来源：https://blog.csdn.net/qq_42135121/article/details/99693028

标签

偏移量

offset