mysql执行offset时并非跳过前n行，而是逐行扫描、计数并丢弃前n行，导致i/o和cpu开销与offset值线性正相关；应优先采用游标分页（where+排序字段值）或延迟关联优化。
MySQL执行OFFSET时必须逐行扫描并丢弃前N行
不是“跳过”，而是“先读、再计数、再丢弃”。LIMIT 100000, 20 实际会让MySQL从索引头开始，挨个读取至少100020条记录，对每一条做排序位置判断，前10万条不返回但照常解析、回表、计入Buffer Pool——I/O和CPU开销与OFFSET值线性正相关。
常见错误现象：EXPLAIN中rows显示几十万甚至上百万，Extra列出现Using filesort或空值（说明没走覆盖索引）；高并发下Buffer Pool被大量无效页占满，拖慢其他查询。
- 即使
ORDER BY id有主键索引，B+树仍需遍历大量叶子节点才能“数够”10万行 - 若排序字段无索引，或
WHERE条件与ORDER BY不匹配最左前缀，直接退化为全表扫描+临时文件排序 -
OFFSET传负数或非整数时，MySQL报错ERROR: OFFSET must not be negative，但业务层未校验会导致500或静默失败
回表放大了深分页的IO灾难
二级索引只存排序字段+主键，LIMIT offset, size查到主键后，还得根据这些主键逐一回聚簇索引取完整行——OFFSET 100000意味着10万次随机磁盘IO（或Buffer Pool查找），远超顺序扫描成本。
使用场景：后台导出、数据稽核等需跳转任意页的场景，但千万级表上应避免直接暴露大OFFSET。
- 强制覆盖索引可缓解：例如只
SELECT id, title FROM posts ORDER BY created_at DESC LIMIT 100000, 20，避免回表 - 延迟关联（Deferred Join）更彻底：先用索引查出主键列表，再
JOIN原表批量取详情 - 别迷信“加索引就快”——得看
EXPLAIN里是index还是range访问类型，type=ALL说明索引完全失效
游标分页为什么能绕过OFFSET瓶颈
游标分页把“第N页”转成“比上一页最后一条记录更大的下一批”，MySQL可用索引直接二分定位起点，全程走range扫描，执行时间稳定在毫秒级，与总数据量无关。
关键陷阱在排序字段唯一性：单用created_at DESC，高并发下同一毫秒多条记录，WHERE条件created_at 会漏掉同时间戳的其他行。
- 安全写法必须用复合排序+复合比较：
ORDER BY created_at DESC, id DESC+WHERE (created_at, id) - MySQL 8.0+和PostgreSQL支持行构造器语法，SQLite不支持，得拆成
created_at - 前端必须透传上一页末尾的
last_id或(last_created_at, last_id)，不能由后端拼接字符串，防SQL注入
什么时候还不得不硬扛OFFSET
管理后台需要精确跳转到第N页（如“跳转到第87页”）、且N可控（≤200）、数据量不大（
此时必须加防护：校验page >= 1且page * size ，超限则降级返回空或提示“仅支持前5000页”。
- 禁止在
COUNT(*)查询里复用带LIMIT/OFFSET的DB实例，GORM等ORM会忽略这些条件导致总数不准 -
ORDER BY字段必须有索引，且与WHERE条件组合符合最左前缀，否则优化器大概率放弃索引 - 首次请求游标分页仍需全排序取首屏，所以
WHERE条件越早收敛越好（比如加status = 'active'）
游标分页看似只改一行WHERE条件，但背后依赖排序字段的单调性、索引设计、前后端协作约定——少一个环节，就可能漏数据或重复。真正上线前，务必用真实数据压测第1000页、第5000页的响应时间和一致性。
