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 <= 100（防恶意拉取巨量数据）计算 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。 VWO 一个A/B测试工具