深分页
- 问题
- 优化方法
- 子查询
- 延迟关联
- 游标
问题
就是查询偏移量过大的场景，会导致查询性能较低，例如
# MySQL 在无法利用索引的情况下跳过1000000条记录后，再获取10条记录
SELECT * FROM t_order ORDER BY id LIMIT 1000000, 10
首先，原因是MySQL并不会跳过这个offset行去查询，而是直接查询前 offer + N 行，然后返回的时候把前 offset 行放弃，返回 N 行，即返回(offset， offset + N)行，所以导致MySQL查询分页OFFSET越大，查询性能越差。
此时的查询流程为：
- 查询前offset + N 项记录（包含所有需要字段）
- 放弃前 offset 项记录
- 返回 剩下的 N 项记录
阿里巴巴的《Java开发手册》里面有提到这个问题：
并且给出了解决方法：
- 先获取到id列表，再根据id列表去查询数据。
优化方法
子查询
子查询： 先获取到id列表，再根据id列表去查询数据。
# 通过子查询来获取 id 的起始值，把 limit 1000000 的条件转移到子查询
SELECT * FROM t_order WHERE id >= (SELECT id FROM t_order limit 1000000, 1) LIMIT 10;
但子查询的结果会产生一张新表，会影响性能，应该尽量避免大量使用子查询。当然，我们也可以利用子查询先去获取目标分页的 ID 集合，然后再根据 ID 集合查询。
延迟关联
延迟关联与基于子查询的优化方式类似，也是通过减少回表的记录数提高查询效率, 都是把条件转移到主键索引树。不同点是，延迟关联使用了 INNER JOIN（内连接） 包含子查询。
SELECT t1.* FROM t_order t1
INNER JOIN (SELECT id FROM t_order limit 1000000, 10) t2
ON t1.id = t2.id;
游标
limit 深分页问题的本质原因就是：偏移量（offset）越大，mysql就会扫描越多的行，然后再抛弃掉。这样就导致查询性能的下降。可以采用游标，就是标记一下上次查询到哪一条了，下次再来查的时候，从该条开始往下扫描，比如某平台的下拉获取新数据。
select id,name FROM user where id > 1000000 limit 10;
