LIMIT 越大查询越慢，因MySQL需扫描offset+size行后丢弃前offset行；偏移量越大，无效扫描越多，且SELECT *易触发回表放大I/O。
为什么 LIMIT 越大查询越慢？
因为 MySQL 在执行 SELECT * FROM t ORDER BY id LIMIT 10000, 20 这类语句时，即使有 id 索引，也得先扫描前 10020 行，再丢弃前 10000 行——ORDER BY + LIMIT 的偏移量（offset）越大，扫描的无效行越多。
更糟的是，如果 SELECT * 涉及非索引列，还会触发回表，进一步放大 I/O 开销。
常见错误现象：EXPLAIN 显示 rows 高达几十万，但实际只返回 20 行；慢查询日志里 Query_time 随 offset 线性增长。
用覆盖索引把 SELECT * 换成 SELECT id
核心思路：让查询完全走索引，不回表、不读数据页。前提是排序字段和查询字段都在同一个索引里。
实操建议：
- 给常用分页字段建联合索引，例如：
ALTER TABLE t ADD INDEX idx_cover (status, create_time, id)，其中status是高频过滤条件，create_time是排序字段，id是主键（用于后续关联查详情） - 分页 SQL 改为只查索引列：
SELECT id FROM t WHERE status = 1 ORDER BY create_time DESC LIMIT 10000, 20—— 此时EXPLAIN的Extra会显示Using index - 拿到
id列表后，用IN查详情：SELECT * FROM t WHERE id IN (123, 456, ...)；注意IN列表长度别超max_allowed_packet，一般控制在 1000 以内
WHERE id > ? 替代 LIMIT offset, size
适用于「按主键或唯一递增字段分页」的场景，比如时间线、订单列表。它绕开了 offset 扫描，直接定位起点。
使用条件：
- 排序字段必须是单调递增/递减且几乎无重复（如
id、create_time+ 唯一约束） - 不能跳页，只能「下一页」「上一页」；用户点击第 100 页会失效
- 第一次查需带初始值，例如：
SELECT * FROM t WHERE status = 1 AND id > 1000 ORDER BY id ASC LIMIT 20 - 下一页继续用上一页最后一条的
id：假设上一页最后id = 1019，则下一页是id > 1019
性能差异明显：WHERE id > ? 是索引范围扫描，rows ≈ 20；而 LIMIT 10000,20 是全索引扫描前 10020 行。
为什么加了索引还是慢？这几个点容易被忽略
覆盖索引不是万能的。以下情况仍可能慢：
- 排序字段有
NULL值且未在索引中显式处理，MySQL 可能放弃使用该索引做ORDER BY - 联合索引顺序错：比如
ORDER BY create_time DESC，但索引是(id, create_time)，则无法利用索引排序，仍要 filesort -
WHERE条件用了函数或隐式类型转换，例如WHERE DATE(create_time) = '2024-01-01'，导致索引失效 - 表数据量极大（> 千万行）且并发高，即使覆盖索引，单次
IN查询也可能锁住大量索引记录，引发锁等待
最常被忽略的是：没验证 EXPLAIN 的 key 和 Extra 字段是否真用了预期索引——光建了索引不等于被用。
