直接用 LIMIT offset, count 会导致性能下降和数据错乱，因其需扫描并丢弃前 offset 行；游标分页通过 WHERE + 索引字段（如 id > last_id）避免跳过与重复，要求排序字段唯一或强单调。
为什么直接用 LIMIT offset, count 会出问题
因为 MySQL 必须扫描并读取前 offset + count 条记录，再丢弃前 offset 条——数据越往后，跳过的行越多，I/O 和排序开销越大。更麻烦的是：如果分页期间有新记录插入或旧记录删除，LIMIT 10000, 10 可能漏掉数据、重复显示，甚至跳过整页。
怎么让分页不跳、不重、不慢
用游标分页（cursor-based pagination），也就是基于上一页最后一条记录的值来定位下一页起始点。核心是放弃数字偏移量，改用 WHERE + 索引字段过滤。
- 必须有确定排序依据，且该字段有唯一性或强单调性（如
id、created_at） - 上一页查完后，记住最后一条的
id值（比如last_id = 12345） - 下一页查询写成：
SELECT * FROM orders WHERE id > 12345 ORDER BY id LIMIT 10 - 如果按时间倒序，用
created_at DESC，则条件要写成WHERE created_at ，注意方向匹配 - 不能用
ORDER BY RAND()配合游标——随机顺序无法定义“下一页”
LIMIT 和 ORDER BY 必须一起出现
没 ORDER BY 的 LIMIT 查询结果顺序不可靠。InnoDB 不保证物理顺序恒定，尤其在 MVCC、页分裂、批量导入后，同一语句多次执行可能返回不同行。
- 错误写法：
SELECT * FROM users LIMIT 10 - 正确写法：
SELECT * FROM users ORDER BY id ASC LIMIT 10或ORDER BY created_at DESC LIMIT 10 - 排序字段最好建索引；复合排序（如
ORDER BY status, id）需对应联合索引，否则仍可能触发 filesort
大偏移量场景下，LIMIT 还能抢救吗
如果业务强依赖页码（比如 SEO 友好链接、后台管理页码跳转），又无法改造成游标，可考虑“延迟关联”或子查询优化：
- 低效原句：
SELECT * FROM articles ORDER BY id DESC LIMIT 1000000, 20 - 优化写法：
SELECT a.* FROM articles a INNER JOIN (SELECT id FROM articles ORDER BY id DESC LIMIT 1000000, 20) b ON a.id = b.id - 原理：子查询只取
id（覆盖索引），主表再回表查完整字段，减少 I/O 量 - 但依然不如游标分页稳定高效，仅作兜底方案
真正难处理的不是语法怎么写，而是“页码”这个概念本身在高并发、动态数据场景下就存在逻辑缺陷——游标分页不是替代方案，是更贴近数据本质的表达方式。
