OFFSET/FETCH仅支持最外层查询，不可嵌套或与ROW_NUMBER()联合控制偏移；其性能随offset增大线性下降，深度分页应改用ROW_NUMBER()或游标分页。
OFFSET FETCH 本身不能和窗口函数直接配合使用
很多人尝试写类似 SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM t ORDER BY id OFFSET 10 ROWS FETCH NEXT 5 ROWS ONLY，再在外面套一层过滤 WHERE rn BETWEEN 11 AND 15 —— 这种写法逻辑上看似合理，但实际无效。SQL 标准规定：OFFSET/FETCH 只能出现在最外层的 ORDER BY 子句之后，且执行顺序在窗口函数计算之后、结果集截断之前；但你无法在同一个查询层级里用窗口函数结果去控制 OFFSET 的偏移量。
物理分页必须靠 ORDER BY + OFFSET FETCH，窗口函数只能辅助校验或补全
真正高效的物理分页只依赖确定性排序 + OFFSET/FETCH，窗口函数在这里的作用很有限：
-
ROW_NUMBER()可用于调试：比如加个COUNT(*) OVER()查总条数，但会拖慢性能（需全表扫描） - 若业务需要“第 N 页共 M 页”这种信息，建议用两步查：先
SELECT COUNT(*)（加覆盖索引），再执行带OFFSET/FETCH的主查询 - 不要试图用
ROW_NUMBER()替代OFFSET——它不会跳过前 N 行，而是给每行打序号，仍需后续WHERE过滤，导致无法利用索引下推
为什么 OFFSET 越大越慢？怎么缓解
数据库执行 OFFSET 100000 FETCH NEXT 20 时，必须先定位到排序后的第 100001 行，中间所有行都得扫描、排序、丢弃。这是物理分页的固有代价。
- 确保
ORDER BY字段有高效索引，例如CREATE INDEX idx_sort ON t (status, created_at, id)（复合索引要匹配查询中的排序和等值条件） - 避免在
OFFSET很大的场景下用物理分页；改用游标分页（WHERE created_at ） - PostgreSQL 中可考虑
TABLESAMPLE或物化路径做近似分页，但不适用于精确场景
SQL Server 和 PostgreSQL 的 FETCH 语法差异要注意
虽然都支持 OFFSET/FETCH，但细节容易出错：
- SQL Server 要求必须有
ORDER BY才能用OFFSET，否则报错"The OFFSET clause is invalid" - PostgreSQL 允许
OFFSET不带ORDER BY（但结果无意义），且FETCH FIRST 5 ROWS ONLY和FETCH NEXT 5 ROWS ONLY等价 - MySQL 8.0+ 支持但语法是
LIMIT 10, 5，不兼容OFFSET/FETCH；别在跨库抽象层里硬套标准语法 - Oracle 12c+ 用
OFFSET ... ROWS FETCH NEXT ... ROWS ONLY，但对NULLS FIRST/LAST的处理和 PostgreSQL 不一致，排序稳定性要额外验证
窗口函数和 OFFSET/FETCH 是两条平行线：一个负责行内计算，一个负责结果集裁剪。想靠它们“配合”实现高效分页，本质是混淆了执行模型。真要兼顾性能和页码感知，得靠索引设计 + 游标 + 应用层缓存，而不是在单条 SQL 里堆砌语法。
