SQL优化之深分页
我们都知道，大型项目中的SQL语句，应该尽量避免深分页。
那么问题就来了：
- 深分页的性能差在哪？
- 什么方案能避免深分页呢？
什么是深分页
深分页，即SQL查询过程中，使用的页数过深，数据库执行的过程中，需要遍历前面很多数据并跳过后，才返回数据的过程。
这种情况会导致SQL查询变慢；
深分页的性能问题
上面介绍了深分页的描述，那下面具体看下深分页的性能问题。
1、覆盖索引
select uid from user_info limit 100, 10;
select uid from user_info limit 10000, 10;
select uid from user_info limit 1000000, 10;
select uid from user_info limit 2000000, 10;
在查询语句能够命中覆盖索引的情况下，可以看到查询范围在[2000000,2000010]的10条数据，耗时近200ms。对于线上千万级的数据表来说，即使查询不需要回表，那也是妥妥的慢查询，
2、非覆盖索引
select * from user_info limit 100, 10;
select * from user_info limit 10000, 10;
select * from user_info limit 1000000, 10;
select * from user_info limit 2000000, 10;
同样的查询范围，对于需要回表的SQL查询，耗时提高了近4倍，查询效率更低。
深分页的优化
1、Inner Join
使用Inner Join提高深分页，原理是减少查询时的回表次数；
利用id的有序性，通过子查询获取到指定记录的一组id，再查询id对应的记录。
select * from user_info limit 2000000, 10;
select * from user_info
inner join (select uid from user_info limit 2000000, 10
) as sub on sub.uid = user_info.uid;
2、边界记录
上面的Inner Join 用到了子查询，对性能还是有一定的影响；
如果业务中的页遍历是顺序的，没有跨页的情况，那可以考虑对每次查询接结果，记录返回的最大id，作为下一次查询的开始id。
这样就能避免子查询的使用，同时减少回表次数。
select * from user_info where id >= 2000010 limit 10;
总结
对于深分页问题，无论是使用Inner Join、还是记录上一个id，核心思路都是要降低回表次数。
