offset fetch 必须写在 order by 后面，因为 sql server 强制要求其仅出现在含 order by 的查询末尾，否则报错“incorrect syntax near 'offset'”；常见错误包括 order by 位置错误、排序字段未出现在 select 列表中、或在视图/函数调用时遗漏外层 order by。
OFFSET FETCH 不是比 TOP “更灵活”，而是更直观、更标准——但必须搭配 ORDER BY，且深度分页时性能会明显劣于合理设计的 TOP + WHERE 方案。
为什么 OFFSET FETCH 必须写在 ORDER BY 后面？
SQL Server 强制要求 OFFSET 只能出现在含 ORDER BY 的查询末尾。不写或顺序错，直接报错：Msg 102, Level 15, State 1, Line X Incorrect syntax near 'OFFSET'。
- 常见错误：把
ORDER BY放在OFFSET后面（语法不允许） - 常见错误：用
SELECT *，但ORDER BY id字段在结果集中被隐藏（比如视图里没暴露排序字段） - 常见错误：在内联表值函数中用了
OFFSET，但调用该函数时没补ORDER BY—— 函数内部的OFFSET不生效
OFFSET 参数怎么算才不会跳错页？
前端传的是 page 和 page_size，SQL 层必须手动转成偏移量，不能直接代入。
- 第 1 页 →
OFFSET 0 ROWS - 第 3 页、每页 20 条 →
OFFSET (@page - 1) * @page_size ROWS即OFFSET 40 ROWS - 必须写
FETCH NEXT @page_size ROWS ONLY，漏掉ONLY会语法报错 - 示例（查第 3 页，每页 20 条）：
SELECT id, name FROM users ORDER BY id OFFSET 40 ROWS FETCH NEXT 20 ROWS ONLY;
OFFSET 比 TOP 慢的根本原因是什么？
不是语法问题，是执行逻辑：SQL Server 必须先扫描并跳过前 N 行，哪怕这些行早就在索引里“看得到”。OFFSET 100000 不代表只定位第 100001 条，而是要逻辑读前 100000 + FETCH 行数，再丢弃前面的。
- 即使
ORDER BY字段有索引，也无法避免扫描放大 - 实测：20 万数据，
OFFSET 10000平均耗时约 70ms；OFFSET 100000耗时可能突破 300ms - 此时
TOP+WHERE id > last_seen_id（键集分页）反而更快、更稳定 - 别只看写法简洁——打开执行计划，重点看「实际行数」和「逻辑读次数」
真正容易被忽略的，不是怎么写 OFFSET，而是它在高偏移量下行为不可控：同一语句，数据量微增或统计信息过期，就可能触发完全不同执行计划，响应时间从 20ms 跳到 2s。上线前务必用真实数据量压测第 100 页、第 500 页的实际耗时。
