offset fetch 比 row_number() 更快，因引擎可直接跳过前n行物理数据，无需全表排序编号；但需order by加索引，且大偏移量仍受限于b+树遍历开销。
OFFSET FETCH 为什么比 ROW_NUMBER() 更快
因为数据库引擎能直接跳过前 N 行物理数据，不用为整张表每行都生成序号。ROW_NUMBER() 要先扫全表、排序、编号，再过滤，IO 和内存开销都大得多。
实操建议：
- 必须在
ORDER BY子句存在且字段有索引时才生效，否则性能反而更差 - 当
OFFSET值很大（比如 >10万），即使有索引，扫描跳过的页数仍会拖慢响应——这不是语法问题，是 B+ 树遍历的固有限制 - SQL Server 2012+、PostgreSQL 8.4+、Oracle 12c+ 支持；MySQL 直到 8.0.12 才支持
OFFSET ... FETCH，旧版只能用LIMIT offset, size
写存储过程时怎么安全传入 OFFSET 和 FETCH 参数
不能直接拼字符串，否则必然 SQL 注入。必须用参数化查询，且对数值做范围校验。
实操建议：
- 在存储过程中声明
@page_index和@page_size，并限制@page_size （防恶意拉取巨量数据） - 计算
OFFSET时用(@page_index - 1) * @page_size，注意避免负数或溢出（@page_index必须 ≥ 1） - SQL Server 示例：
SELECT * FROM orders ORDER BY created_at DESC OFFSET (@page_index - 1) * @page_size ROWS FETCH NEXT @page_size ROWS ONLY;
遇到 “Invalid usage of the option NEXT in the FETCH statement” 错误怎么办
这是 SQL Server 的典型报错，说明 FETCH 写法不合法——最常见原因是漏了 ORDER BY，或者 FETCH 前没写 OFFSET。
实操建议：
-
OFFSET ... FETCH是绑定对，不能只写FETCH；也不能写成FETCH @size ROWS（变量不被允许，必须是字面量或参数） - SQL Server 要求
OFFSET后必须跟ROWS，FETCH后必须跟NEXT ... ROWS ONLY，少一个词都报错 - 如果用动态 SQL 拼接，检查最终语句是否含
ORDER BY，且OFFSET和FETCH位置、大小写、空格都符合语法
分页深度变大后响应越来越慢，光靠 OFFSET FETCH 不够怎么办
OFFSET 越大，数据库越要“数着跳过”前面所有行，本质是线性扫描成本。这不是 bug，是设计使然。
实操建议：
- 用游标分页（cursor-based pagination）替代页码分页：记录上一页最后一条的
created_at和id，下一页查WHERE (created_at, id) - 对高频分页字段建联合索引，如
CREATE INDEX idx_orders_time_id ON orders(created_at DESC, id DESC) - 业务上限制最大可访问页码（如只允许查前 1000 页），或改用搜索 + 排序 + 滚动加载，避开深度分页场景
OFFSET FETCH 看似简单，但真正在高偏移、大数据量、多并发下扛住压力，得配合索引策略、参数防护和分页模型切换——单靠语法糖解决不了底层扫描代价。
