sql server用offset fetch分页越往后越慢，因offset必须真实扫描并丢弃前n行，即使只取20条，offset 100000也要读100002行，这是设计机制而非索引失效，适用于数据量小的场景。
SQL Server 用 OFFSET FETCH 分页时，为什么越往后翻越慢？
因为 OFFSET 必须跳过前面所有行，数据库得真实扫描、丢弃前 N 行——哪怕你只要 20 条，OFFSET 100000 ROWS 就得先读 100002 行。这不是索引失效，是设计使然。
- 适用场景：数据量小（
- 别在高并发列表页盲目套用
OFFSET/FETCH，尤其当ORDER BY字段不是主键或唯一索引开头时，性能会断崖下跌 -
ORDER BY必须有确定性排序，否则同页数据可能重复或丢失（比如两个记录created_at相同但没加二级排序字段）
PostgreSQL 的 OFFSET FETCH 和 SQL Server 有啥关键区别？
语法一致，但 PostgreSQL 在 OFFSET 很大时更容易触发顺序扫描，尤其当 WHERE 条件无法高效过滤时；而 SQL Server 会更早尝试用索引跳转，但依然绕不开跳行成本。
- PostgreSQL 中，如果
ORDER BY id且id是主键，OFFSET 50000可能比ORDER BY created_at快 3 倍以上 - 两者都不支持在同一个查询中动态改
OFFSET值（比如写成OFFSET @page * @size），必须拼接或用参数化查询，否则计划缓存易失效 - PostgreSQL 14+ 支持
WITH TIES配合FETCH，但仅限于ORDER BY末尾字段存在重复值时保一致性，不是通用优化手段
什么时候该放弃 OFFSET FETCH，改用「游标分页」？
当你发现第 500 页开始响应超 1s，或者监控里看到 Sort / Top N Sort 算子占执行时间 70% 以上，就是明确信号。
- 游标分页核心是记住上一页最后一条的排序字段值，例如上页最后
id = 12345，下页查WHERE id > 12345 ORDER BY id FETCH NEXT 20 ROWS ONLY - 必须确保
ORDER BY字段有索引，且该字段组合在业务中不会重复（或用(id, created_at)这类复合唯一排序） - 不能跳页（比如从第 1 页直接到第 100 页），但对无限滚动、下拉加载等场景更稳、更快、更可扩展
存储过程中写分页逻辑，怎么避免参数嗅探导致执行计划劣化？
SQL Server 存储过程默认用第一次传入的参数生成执行计划，如果首次调用是 @offset = 0，后续大偏移量就可能复用全表扫描计划，而不是索引查找。
- 显式加
OPTION (RECOMPILE)是最直接的解法，但会增加编译开销，适合每页请求频率不高（如管理后台） - 用局部变量“断开”参数直连：把
@offset赋值给DECLARE @o INT = @offset，再在查询中用@o，SQL Server 通常会为不同值生成不同计划 - 不要在存储过程里拼接字符串做分页（如
EXEC('SELECT ... OFFSET ' + @sql_offset)），既难审计又易注入，还绕不开参数嗅探
游标分页的边界值处理、多字段排序的稳定性、以及如何让前端安全传递游标值——这些才是实际落地时真正卡住人的地方。
