row_number()必须配合over子句使用，否则报错；它属窗口函数，强制要求order by排序且推荐加唯一字段保证稳定性，分页时需注意索引、嵌套层级与数据库差异。
ROW_NUMBER() 必须搭配 OVER 子句，否则直接报错
单独写 ROW_NUMBER() 会触发类似 "Window function requires OVER clause" 的错误。它不是普通函数，而是窗口函数，必须明确指定排序逻辑和分区范围。分页场景下几乎总是用 OVER (ORDER BY ...)，且 ORDER BY 的字段最好有索引，否则性能会断崖式下降。
常见错误是照抄示例却忽略排序字段的业务含义——比如按 id 排和按 created_at 排，在数据插入乱序时结果完全不同；更隐蔽的是没加 ASC/DESC 显式声明，默认 ASC，但业务上可能需要最新数据在前。
子查询嵌套层级要控制在两层以内
典型分页写法是外层筛选 rn BETWEEN ? AND ?，内层生成行号。三层及以上嵌套（比如再套一层聚合或 JOIN）会让执行计划变复杂，MySQL 8.0+ 和 PostgreSQL 虽支持，但 SQL Server 对深度嵌套的优化较弱，容易跳过索引。
实操建议：
- 把过滤条件尽量下推到最内层子查询（如
WHERE status = 'active'），减少行号计算的数据量 - 避免在
OVER的ORDER BY中使用函数（如ORDER BY UPPER(name)），这会让索引失效 - PostgreSQL 中可考虑用
LIMIT/OFFSET替代，简单分页更快；但OFFSET超过几十万行后性能劣化明显，此时ROW_NUMBER()+ 覆盖索引仍是更稳的选择
分页参数传入需防 SQL 注入和越界
分页常通过 pageNo 和 pageSize 计算 start 和 end，例如 (pageNo - 1) * pageSize + 1。若未校验，pageNo = -1 或 pageSize = 0 会导致 rn BETWEEN 0 AND -1 这类无意义范围，部分数据库返回空结果却不报错，前端卡在加载状态。
安全做法：
- 服务端强制校验
pageNo >= 1、pageSize在 1–100 之间 - 用参数化查询，绝不用字符串拼接构造
WHERE rn BETWEEN ? AND ? - 对超大偏移做兜底：比如总记录数已知为 1000，
pageNo = 200时直接返回空数组，不执行 SQL
SQL Server 与 MySQL 8.0+ 的语法差异点
MySQL 8.0+ 支持 ROW_NUMBER()，但旧版只能靠变量模拟，稳定性差；SQL Server 全版本支持，但注意 TOP 和 ROW_NUMBER() 混用时的语义冲突——TOP 10 是物理前 10 行，而 ROW_NUMBER() 是逻辑排序后编号，两者顺序不一致就出错。
一个易被忽略的坑：
- SQL Server 中若
ORDER BY字段存在重复值（如多个created_at相同），ROW_NUMBER()仍会强制分配唯一序号，但两次执行结果可能因内部排序不稳定而不同；解决方案是在ORDER BY末尾追加主键（如ORDER BY created_at DESC, id DESC）保证确定性 - MySQL 8.0+ 同样要求确定性排序，否则分页翻页时可能漏数据或重复
跨数据库移植时，别只盯着函数名，排序的稳定性和索引覆盖才是分页不翻车的核心。
