limit 1000000,20变慢是因为mysql需扫描并丢弃前1000000行，引发大量随机i/o和cpu过滤开销；优化可用延迟关联（覆盖索引+子查询）或游标分页（where id > 上次末id）。
为什么 LIMIT 1000000, 20 会查得越来越慢？
不是因为取 20 条数据慢，而是数据库必须先扫描、排序、回表前 1000000 行——哪怕它们全被丢弃。InnoDB 在二级索引上按顺序扫到第 1000020 个节点，拿到对应主键，再拿着这 1000020 个 id 去聚簇索引里逐个回表查完整行。这 100 万次随机 I/O 和内存搬运，才是性能崩塌的根源。
常见现象包括：EXPLAIN 中 type 变成 index 或 ALL，Extra 出现 Using filesort 或 Using temporary，查询耗时从毫秒级跳到秒级甚至超时。
怎么用覆盖索引 + 延迟关联把查询压到 0.1 秒内？
核心是拆成两步：第一步只走索引查 id，第二步精准回表。只要索引能覆盖排序和过滤条件，子查询就完全不碰数据页。
- 必须建联合索引，例如按
create_time排序分页，且带WHERE status = 1，那就建INDEX(status, create_time, id)——id放最后，确保覆盖索引生效 - SQL 写成：
SELECT t1.* FROM orders t1 INNER JOIN ( SELECT id FROM orders WHERE status = 1 ORDER BY create_time DESC LIMIT 1000000, 20 ) t2 ON t1.id = t2.id;
- MyBatis 中直接传参：
#{offset}和#{size}进子查询，外层不变，无需改业务逻辑 - 注意：如果排序字段有重复（比如多个订单同秒创建），
ORDER BY create_time DESC, id DESC才能保证结果稳定，否则可能漏/重
游标分页比 OFFSET 快在哪？
它彻底绕开“跳过 N 行”这个动作，转而用条件过滤直接定位起点。比如上一页最后一条是 id = 1058，下一页就查 WHERE id > 1058 ORDER BY id LIMIT 20，数据库直接走索引范围扫描，复杂度从 O(N) 降到 O(1)。
- 前端必须传回完整游标值（如
{"created_at": "2025-03-15T09:23:41Z", "id": 98765}），不能只传页码或简单拼id > xxx - 复合索引必须匹配查询顺序：
CREATE INDEX idx_cursor ON orders(created_at DESC, id DESC) - 若排序字段允许重复（如
status），必须加二级排序字段，否则游标边界模糊，结果不可控 - 不适用于跳页场景（如用户手动输入“第 500 页”），此时延迟关联仍是兜底方案
哪些细节最容易被忽略？
覆盖索引没建对、游标没传全、排序字段没加唯一约束——这三个点一错，优化就白做。
比如只建了 INDEX(create_time)，但子查询里 WHERE status = 1 一加，立马退化为全索引扫描；又或者前端把游标值截断成字符串再解析，导致精度丢失；再或者用 created_at 单字段游标，而该字段在高并发写入下大量重复，就会漏掉同时间的多条记录。
