SQL Server中OFFSET FETCH必须配合ORDER BY，否则报错；因无显式排序则行序不确定，分页结果不稳定，且重复值需加唯一列兜底；参数须参数化传入，OFFSET非负、FETCH为正整数；深分页性能差，建议改用键集分页。
OFFSET FETCH 是 SQL Server 2012 引入、在 2022 中依然适用的标准分页方案，它比 ROW_NUMBER() + 子查询更简洁，也比 TOP + 嵌套更可控。但直接套用容易出错——尤其是排序不唯一、OFFSET 越界或参数绑定不当的时候。
为什么必须有 ORDER BY 才能用 OFFSET FETCH
SQL Server 强制要求 OFFSET FETCH 必须配合 ORDER BY，否则报错：The OFFSET clause cannot be used without an ORDER BY clause. 这不是限制，而是保障分页结果稳定的前提。
- 没有
ORDER BY，行顺序由查询优化器决定，每次执行可能不同，分页会“跳行”或“重复” - 即使表有主键，也不代表默认按主键排序；显式写
ORDER BY id才算数 - 如果排序字段存在重复值（比如多个订单的
created_date相同），建议补一个唯一列兜底：ORDER BY created_date DESC, id DESC
OFFSET FETCH 的参数怎么传才安全
实际业务中，OFFSET 和 FETCH NEXT 往往来自用户输入（如页码、每页条数），直接拼字符串极危险，必须用参数化查询。
- 错误写法：
OFFSET ' + @page + ' ROWS FETCH NEXT ' + @size + ' ROWS ONLY→ SQL 注入风险 - 正确做法：所有变量都作为参数传入，例如在 C# 中用
SqlCommand.Parameters.AddWithValue绑定@offset和@fetch -
OFFSET值不能为负数，SQL Server 会报错：Incorrect syntax near 'OFFSET'.（其实是解析失败） -
FETCH NEXT后面必须是正整数，FETCH NEXT 0 ROWS ONLY不合法，会报错：A non-negative number is required.
OFFSET 越大性能越差？怎么缓解
是的。OFFSET 10000 ROWS 意味着 SQL Server 必须先扫描并跳过前 10000 行，再取后续数据，I/O 和 CPU 开销随偏移量线性增长。
- 10 万行以内、
OFFSET小于 5000 时，表现尚可；超过后响应明显变慢 - 替代思路：改用「游标分页」（keyset pagination），比如记录上一页最后一条的
id，下一页查WHERE id - 确保
ORDER BY字段有索引，且索引包含查询所需列（覆盖索引），否则回表成本高 - 避免在视图或复杂子查询上直接套
OFFSET FETCH，先物化中间结果（如用 CTE 或临时表）有时反而更快
真正难的不是写出语法正确的 OFFSET FETCH，而是保证排序稳定、参数安全、性能可控——尤其当数据量涨到百万级、用户疯狂点“下一页”时，那个没加唯一兜底的 ORDER BY 就会悄悄返回错乱结果。
