窗口函数不支持在OVER()中使用LIMIT，正确分页需先用ROW_NUMBER()等生成序号，再在外层WHERE中筛选范围；ORDER BY必须包含唯一字段（如主键）以保证分页稳定性。
窗口函数本身不支持 LIMIT，别在 OVER() 里写 LIMIT
窗口函数（如 ROW_NUMBER()、RANK()）是计算值的，不是筛选行的。你在 OVER() 子句里加 LIMIT 会直接报错，比如 PostgreSQL 报 syntax error at or near "LIMIT"，MySQL 8.0 也一样不认。
真正想分页，得把窗口函数结果当成子查询或 CTE 的一部分，再在外层用 LIMIT + OFFSET（或 FETCH FIRST）控制输出行数。
- 错误写法：
SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM t LIMIT 10—— 这只限制最终结果，但ROW_NUMBER()仍基于全表计算，性能差且语义不清 - 正确思路：先算好序号，再筛指定范围，比如第 2 页（每页 10 条）就取
rn BETWEEN 11 AND 20 - 注意：窗口函数执行顺序早于
LIMIT，所以外层过滤必须靠 WHERE 或 HAVING，不能指望LIMIT帮你“截断”窗口逻辑
用 ROW_NUMBER() 实现稳定分页，ORDER BY 必须唯一
如果只按 created_at 排序，而多行时间相同，ROW_NUMBER() 会任意分配不同序号，导致同一页数据每次查出来不一致，甚至漏行、重复。
解决办法是在 ORDER BY 里补一个唯一字段兜底，通常是主键：
SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY created_at DESC, id DESC) AS rn FROM posts ) t WHERE rn BETWEEN 11 AND 20
- 不加
id时，两次查询可能对相同时间戳的行编号不同，分页偏移就错乱 - MySQL 8.0 / PostgreSQL / SQL Server 都遵循这个行为；SQLite 3.25+ 也支持，但旧版不支持窗口函数
- 如果业务上真没唯一字段可兜底，至少加
ORDER BY ... , (random())（PostgreSQL）或ORDER BY ... , (SELECT NULL)（兼容性更强），但稳定性仍不如真实唯一键
OFFSET 分页在大数据量下变慢，替代方案看场景
LIMIT 10 OFFSET 10000 要跳过前 10000 行再取 10 行，数据库仍需扫描并丢弃那 10000 行，I/O 和 CPU 成本随偏移量线性增长。
- 适合场景：总数据量小（
- 大偏移量替代法：用上一页最后一条的排序字段值做条件（游标分页），例如
WHERE created_at - 窗口函数无法绕过 OFFSET 性能问题——它只是帮你生成序号，不改变底层扫描逻辑
- 某些 ORM（如 Django 3.1+）对
Window表达式 +limit/offset生成的 SQL 仍是传统分页，别误以为用了窗口函数就自动优化了
不同数据库对窗口函数 + 分页的支持细节
语法看似统一，但实际行为有坑。比如 MySQL 8.0 允许在派生表里用窗口函数后接 LIMIT，而 PostgreSQL 要求 CTE 或子查询显式命名，SQL Server 则对子查询嵌套层级更敏感。
- PostgreSQL 安全写法：
WITH ranked AS (SELECT *, ROW_NUMBER() OVER (...) AS rn FROM t) SELECT * FROM ranked WHERE rn BETWEEN ? AND ? - MySQL 8.0 可省 CTE，但若嵌套太深（如三层子查询），可能触发
ERROR 1235 (42000): This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery' - SQLite 3.25+ 支持窗口函数，但不支持
FETCH FIRST，只能用LIMIT+OFFSET，且子查询必须带别名才能引用列 - 所有数据库中，
ROW_NUMBER()和RANK()在分页时表现不同：前者严格连续编号，后者对并列值给相同序号并跳过后续编号，影响BETWEEN区间是否能取满预期行数
分页这件事，核心从来不是“怎么写窗口函数”，而是“怎么让数据库少算、少传、少丢”。序号只是辅助，真正的分页边界得靠 WHERE 条件或游标来卡死，否则窗口函数算得再准，也拦不住 OFFSET 吃掉的那几毫秒延迟。
