为什么 LIMIT 1000000, 20
会越来越慢
MySQL 执行
LIMIT offset, size时，即使有索引，也会先扫描并跳过前
offset行——不是“定位到第 N 行”，而是“逐行计数跳过”。当
offset达到百万级，InnoDB 要在索引树上反复回表或遍历主键 B+ 树，IO 和 CPU 开销陡增。尤其配合
ORDER BY（如按时间倒序），优化器很可能放弃索引覆盖，转而走全索引扫描 + 文件排序。
用 WHERE id > ?
替代大偏移量分页
核心思路：不依赖行号跳过，改用「上次查询最后一条的主键值」作为下一页起点。这要求排序字段必须是**单调、唯一、有索引**的（推荐主键或带唯一约束的时间戳字段）。
第一页：SELECT * FROM orders WHERE status = 1 ORDER BY id DESC LIMIT 20;假设返回的最小
id是
5002341，第二页就写：
SELECT * FROM orders WHERE status = 1 AND id < 5002341 ORDER BY id DESC LIMIT 20;后续每页都用上一页结果集的边界值（如
id）做条件，避免
LIMIT偏移 注意：不能混用
ASC/DESC方向；若按
created_at DESC分页，需用
created_at ，且该字段要有单独索引或为联合索引最左前缀
复合索引如何设计才真正生效
仅给
ORDER BY字段建单列索引不够。如果查询带
WHERE条件（如
status = 1），必须把过滤字段和排序字段组合进同一个联合索引，且顺序要匹配执行逻辑。 错误示例（
status索引 + 单独
id索引）：
INDEX(status),
INDEX(id)→ 优化器大概率选错索引，或无法覆盖排序 正确示例（覆盖过滤+排序+查询字段）：
INDEX(status, id)→
WHERE status = 1 ORDER BY id DESC可走索引范围扫描，无需排序 如果还要查
user_id、
amount等字段，考虑覆盖索引：
INDEX(status, id, user_id, amount)，避免回表 注意：
IN或范围条件（如
status IN (1,2)）后，其右侧字段无法用于排序；此时应把排序字段放在范围条件之前，或改用
id主键做游标
游标分页（Cursor-based Pagination）要注意什么
游标分页本质是把「第 N 页」转化为「从某条记录之后取 M 条」，比传统分页更稳定，但对业务逻辑有隐含要求：
必须保证排序字段**严格唯一**。如果用created_at，并发插入可能产生相同时间戳，导致漏数据或重复；加
id作二级排序可缓解：
ORDER BY created_at DESC, id DESC，对应游标条件写成
WHERE (created_at, id)前端不能跳页（比如直接点“第 100 页”），只能“下一页/上一页”；若需随机跳转，仍得 fallback 到传统分页（但只允许跳到前几百页） 游标值需 Base64 编码传输（如
base64_encode("1623456789|5002341")），防止被篡改或解析出错
删除中间数据会导致游标“跳空”，但不会崩；只是下一页看起来少了几条——这是可接受的最终一致性表现
实际落地时，最容易被忽略的是索引字段顺序与查询条件的匹配关系，以及游标中多字段比较的写法（MySQL 支持元组比较，但必须确保类型一致、NULL 处理明确）。一旦排序字段非唯一又没兜底，漏数据就是静默发生的。
