offset 越大，limit 越慢，因为mysql需扫描并跳过前offset+n行，无法利用索引跳过中间数据，导致深分页性能崩盘；应改用游标分页，以排序字段的上一页末尾值为查询起点。
为什么 OFFSET 越大，LIMIT 越慢
MySQL 在执行 SELECT * FROM t ORDER BY id LIMIT 10000, 20 这类查询时，会先扫描前 10020 行，再丢弃前 10000 行——哪怕你只想要最后 20 行。索引能加速排序和定位，但无法跳过中间大量数据。这就是“深分页”性能崩盘的根本原因。
- 即使
id有主键索引，OFFSET 1000000仍要逐行计数跳过 - 如果
ORDER BY字段不是索引最左前缀，可能触发 filesort，更慢 - 使用
SQL_CALC_FOUND_ROWS会强制全表扫描，已废弃且无意义
用覆盖索引 + 上次 ID 替代 OFFSET
核心思路是：不依赖行号偏移，改用“上次查到的最后一条记录的主键值”作为下一页起点。这要求排序字段必须有索引，且查询字段尽量被该索引“覆盖”。
- 假设按
created_at DESC, id DESC分页，且(created_at, id)是联合索引 - 第一页：
SELECT id, title, created_at FROM posts WHERE status = 1 ORDER BY created_at DESC, id DESC LIMIT 20 - 第二页：取第一页最后一条的
created_at和id（比如'2024-05-01 10:20:30'和12345），然后写：SELECT id, title, created_at FROM posts WHERE status = 1 AND (created_at - 这个 WHERE 条件能完全命中索引，无需跳过任何行
覆盖索引不是加了索引就自动生效
覆盖索引指：查询所需的所有字段，都包含在同一个索引中。MySQL 可直接从索引 B+ 树叶子节点取值，避免回表（即不再访问聚簇索引）。但容易误判。
- 错误示例：
SELECT * FROM posts ORDER BY created_at DESC LIMIT 20—— 即使created_at有索引，*会导致大量回表，失去覆盖意义 - 正确做法：明确列出字段，如
SELECT id, title, created_at，并建联合索引INDEX idx_cover (created_at, id, title) - 注意字段顺序：
ORDER BY字段必须在索引最左，且查询字段顺序不影响覆盖性，但影响索引大小和维护成本 - 用
EXPLAIN看Extra列是否含Using index，而不是只看key是否命中
游标分页不支持“跳转任意页”，但这是设计选择
用上一页末尾值做条件的方案，天然不支持跳到第 100 页或输入页码跳转。这不是缺陷，而是为性能做的必要取舍。
- 用户点击“下一页”“上一页”“加载更多”场景，完全适用
- 如果业务强依赖跳页（比如后台管理），可对小数据量（如
OFFSET ）走传统分页，大数据量切到游标模式 - 不要试图用
WHERE id > ? LIMIT 20代替带时间字段的复合条件——单主键无法处理并发插入、删除导致的“空洞”或重复/漏数据 - 前端需保存上一页最后一条的完整排序键（不止一个字段），后端严格校验类型和 NULL 处理
真正难的是把游标逻辑嵌进业务层：分页参数不再是数字，而是 base64 编码的上一页末尾值；边界情况（如某页刚好 0 条）需要前后端对齐判断逻辑。这些细节比 SQL 本身更容易出错。
