用id>m limit n 取代，比用 limit m,n 快很多，原因在于与利用上了主键索引, 只查询了n条记录. 这种方法很适合数据加载，但是不一定适合前台的翻页场景， 因为ID可能不连续, 在电梯模式的翻页中不适用，只是用扶梯模式的翻页。 select * from 表 where id > 1000000 limit 5 执行一下：0.013s
还有一个简单的优化办法是使用覆盖查询（covering index）查询，然后再跟全行的做join操作。这样可以直接使用index得到数据，而不去查询表，当找到需要的数据之后，在与全表join，获得其他的列。 如： select * from 表 inner join (select id from 表 limit 1000000,5) as lim on 表.id = lim.id
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
sql：select * from 表 limit m offset n.
这是正常的翻页的业务需求.
在一张count为200w的表上执行一下sql：
select * from 表 limit 1000000,5
执行时间：25s
问题：
MySQL里对LIMIT OFFSET的处理方式是，取出OFFSET+LIMIT的所有数据，然后去掉OFFSET，返回底部的LIMIT。
这种方式在offset很高的情况下，如：limit 100000,20，这样系统会查询100020条，然后把前面的100000条都扔掉，这是开销很大的操作，导致慢查询很慢.
如何优化：
用id>m limit n 取代，比用 limit m,n 快很多，原因在于与利用上了主键索引, 只查询了n条记录. 这种方法很适合数据加载，但是不一定适合前台的翻页场景，
因为ID可能不连续, 在电梯模式的翻页中不适用，只是用扶梯模式的翻页。
select * from 表 where id > 1000000 limit 5
执行一下：0.013s
还有一个简单的优化办法是使用覆盖查询（covering index）查询，然后再跟全行的做join操作。这样可以直接使用index得到数据，而不去查询表，当找到需要的数据之后，在与全表join，获得其他的列。
如：
select * from 表 inner join (select id from 表 limit 1000000,5) as lim on 表.id = lim.id
执行时间：0.211s
array_slice 分页?你确定要全部查出来在服务器分页,而不是在数据库中查询某一页的数据