LIMIT和OFFSET深层分页性能差，因MySQL必须扫描并丢弃前offset行，导致I/O和CPU开销随偏移量剧增；易漏行、重复，即使有索引也无法避免回表与全量排序。
为什么不能直接用 LIMIT 和 OFFSET 做深层分页？
当页码很大（比如第10000页）时，OFFSET 99990 会让数据库扫描并跳过前99990行，即使只取10条，性能也会断崖式下降。尤其在高并发或数据量大的场景下，这种写法会拖慢整个查询链路。
嵌套查询的核心思路是：不靠跳过行数，而是靠“定位锚点”——用上一页最后一条记录的主键或唯一排序字段作为下一页的起点条件。
- 适用于有明确排序字段（如
id、created_at）且该字段有索引的表 - 必须保证排序字段值不重复，否则可能漏数据或重复；若无法保证，需组合多个字段（如
ORDER BY created_at, id） - 第一次请求仍可用
LIMIT+OFFSET，但从第二页起应切换为游标式（cursor-based）嵌套写法
怎么写一个安全的两层嵌套分页查询？
典型结构是外层限制数量，内层通过子查询确定边界。例如按 id 降序分页，要取第2页（每页10条），已知第1页最大 id 是 105：
SELECT * FROM posts WHERE id < (SELECT id FROM posts ORDER BY id DESC LIMIT 1 OFFSET 10) ORDER BY id DESC LIMIT 10;
这个写法的问题在于子查询里的 OFFSET 依然低效。更稳妥的是把锚点值传进来，直接用：
SELECT * FROM posts WHERE id < 105 ORDER BY id DESC LIMIT 10;
- 子查询仅用于生成动态锚点（如配合窗口函数或变量），但生产环境建议由应用层计算锚点后拼入主查询
- MySQL 8.0+ 可用
ROW_NUMBER()实现带编号的嵌套，但要注意ORDER BY必须和外层一致，否则结果不可靠 - PostgreSQL 支持
OFFSET的物化优化，但深度分页仍推荐游标方案
不同数据库对嵌套分页的支持差异有哪些？
MySQL 5.7 不支持窗口函数，只能靠自连接或变量模拟行号，容易出错；MySQL 8.0+、PostgreSQL、SQL Server 都原生支持 ROW_NUMBER()，但语法细节不同。
- PostgreSQL 示例（安全可靠）：
SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY id DESC) AS rn FROM posts ) t WHERE t.rn BETWEEN 11 AND 20;
- MySQL 8.0+ 同样可用
ROW_NUMBER()，但ORDER BY字段必须有索引，否则性能不达标 - SQLite 3.25+ 支持窗口函数，但不支持
FETCH FIRST，得靠子查询+LIMIT组合 - Oracle 需用
ROWNUM伪列，但必须嵌套两层（先排序再编号），顺序错一点就全乱
最容易被忽略的三个坑
嵌套分页不是“套个括号就完事”，实际落地时这几个点常导致线上翻车：
-
ORDER BY字段没索引 → 查询变全表扫描，嵌套再漂亮也白搭 - 并发写入导致排序字段重复（比如批量插入时间戳相同）→ 游标偏移后漏/重数据，必须加二级排序字段兜底
- 应用层没校验锚点合法性（比如传入负数
id或不存在的值）→ 返回空结果却不报错，前端以为到底了
真正稳定的分页，从来不是靠一层 SQL 解决的，而是数据库索引、查询结构、应用层状态三者咬合的结果。锚点传错了，再精巧的嵌套也查不到想要的数据。
