LIMIT 1000000,20 越来越慢是因为MySQL需逐行跳过前1000000行，即使有索引也会引发大量IO和CPU开销；应改用WHERE id > 上次最后id实现高效分页。
为什么 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 处理明确）。一旦排序字段非唯一又没兜底，漏数据就是静默发生的。
