offset不能独立分页，必须与limit（mysql/postgresql）或fetch next（sql server/ansi sql 2008+）配合使用，且强制要求order by；否则数据库无法确定跳过后的取行数量，多数报错，如postgresql提示“offset clause cannot be used without limit or fetch”，sql server则直接拒绝执行。
OFFSET 本身不能独立分页，必须和 LIMIT（或 TOP、FETCH）配合使用，否则会报错或返回全部数据。
为什么单独写 OFFSET 10 会报错？
SQL 标准要求 OFFSET 必须出现在 ORDER BY 之后、且必须有 LIMIT（MySQL/PostgreSQL）或 FETCH FIRST（SQL:2008+）配套。不加限制子句时，数据库无法确定“跳过之后取多少行”，多数引擎直接拒绝执行。
- PostgreSQL 报错：
ERROR: OFFSET clause cannot be used without LIMIT or FETCH - MySQL 8.0+ 允许
OFFSET单独存在但实际效果等同于无限制——返回跳过后的全部结果，极易引发性能问题 - SQL Server 不支持
OFFSET独立语法，必须用OFFSET ... ROWS FETCH NEXT ... ROWS ONLY
LIMIT 和 OFFSET 的顺序与参数含义
在 MySQL 和 PostgreSQL 中，LIMIT 放前面更直观，但标准写法是 LIMIT row_count OFFSET offset_row（PostgreSQL 兼容两种顺序），而 OFFSET 的值表示“跳过前 N 行”，不是“从第 N 行开始”——这是常见误解。
- 查第 2 页（每页 10 条）：应写
LIMIT 10 OFFSET 10，不是OFFSET 20 -
OFFSET 0是合法且推荐的起始值，比省略OFFSET更明确 - 避免
OFFSET过大（如 > 100000），会导致全表扫描跳过大量行，响应明显变慢
示例（PostgreSQL）：
SELECT id, title FROM posts ORDER BY created_at DESC LIMIT 10 OFFSET 20;
SQL Server 怎么写等效分页？
SQL Server 不支持 LIMIT/OFFSET，必须用 OFFSET ... ROWS FETCH NEXT ... ROWS ONLY，且 ORDER BY 为强制项（不可省略）。
- 缺
ORDER BY会报错：The OFFSET clause is missing in the ORDER BY clause. - FETCH 子句不可省略，写成
OFFSET 20 ROWS仍会报错 - 若需兼容旧版本（ROW_NUMBER() 嵌套查询，性能更差
示例（SQL Server）：
SELECT id, title FROM posts ORDER BY created_at DESC OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;
OFFSET 分页的真实代价和替代思路
OFFSET 越大，数据库越可能扫描并丢弃大量中间行，尤其在高并发或大数据量场景下，I/O 和 CPU 开销陡增。这不是语法问题，而是设计局限。
- 当
OFFSET超过 50000，建议改用基于游标的分页（如记录上一页最后的created_at和id，用WHERE (created_at, id) 查询） - 复合排序字段必须有联合索引支持，否则游标分页也会变慢
- 业务上允许时，限制最大页码（如只提供前 100 页）比硬扛大 OFFSET 更实际
真正卡住的往往不是怎么写，而是没意识到 OFFSET 在百万级表里跳到第 1000 页时，数据库其实在默默读取并扔掉前 99999 行。
