row_number()是分组页码首选函数，因其能通过partition by实现每组从1开始的连续自然编号，而rank()和dense_rank()因重复值处理机制会导致页码不连续；必须配合over子句使用，且order by不可省略以保证编号确定性。
为什么 ROW_NUMBER() 是分组页码的首选函数
直接用 ROW_NUMBER() 配合 PARTITION BY 就能生成每组独立编号，这是最干净、最可控的方式。其他窗口函数如 RANK() 或 DENSE_RANK() 会因重复值跳号或挤占页码位置，导致页码不连续——而分组页码本质是“每组从 1 开始递增的自然序号”，不是排名。
常见错误是漏写 PARTITION BY，结果得到全表连续编号；或者误用 ORDER BY 字段（比如按时间倒序却期望页码正序），导致页码顺序和业务预期相反。
-
ROW_NUMBER() OVER (PARTITION BY category ORDER BY created_at ASC)：按分类分组，按创建时间升序编号 - 若需“每组内按某字段降序排但页码仍从 1 开始”，
ORDER BY写降序即可，页码逻辑不受影响 - 注意：
PARTITION BY的字段必须和业务分组维度严格一致，比如分组依据是user_id，就不能错写成user_id::text（类型隐式转换可能引发意外分组）
如何把行号转成页码（即每 N 行一页）
窗口函数只给出行号，页码需要额外计算。核心公式是：CEILING(row_num::decimal / page_size)。这里必须转 decimal（或 float），否则整数除法在 PostgreSQL/MySQL 中会截断，导致页码全为 1。
典型场景：导出报表时要求“每个客户订单单独分页，每页 10 条”。这时先用 ROW_NUMBER() 生成组内序号，再套用上式得出页码。
- PostgreSQL 示例：
CEILING(ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_date) / 10.0) - MySQL 8.0+ 同理，但注意
CEILING()对整数除法依然敏感，务必让分母带小数点 - SQL Server 用
CEILING()即可，但需确保分子是DECIMAL类型，可用CAST(... AS DECIMAL(10,2))强制转换
分页偏移量大时性能掉得厉害？别硬算页码
当数据量大、页码靠后（比如第 1000 页），ROW_NUMBER() 必须扫描全部前置行，无法跳过。这不是写法问题，而是窗口函数本身的执行逻辑限制。
如果只是要“取第 N 页的数据”，用 OFFSET + LIMIT 更高效；只有当必须返回“当前行属于第几页”（比如日志打标、前端显示页码态）时，才用窗口函数算页码。
- 导出任务中需标注每条记录所属页码 → 用窗口函数
- API 接口只返回第 5 页的 20 条记录 → 用
OFFSET 80 LIMIT 20，别套窗口函数 - 某些数据库（如 ClickHouse）支持
arrayJoin()拆分页码数组，但通用性差，不建议作为主力方案
不同数据库对 PARTITION BY 和空值的处理差异
PARTITION BY 字段含 NULL 时，各数据库行为不一致：PostgreSQL 和 SQL Server 把所有 NULL 归为同一组；MySQL 8.0 默认也如此，但开启 sql_mode='STRICT_TRANS_TABLES' 后可能报错；Oracle 则把每个 NULL 当独立分组。
这意味着：如果分组字段可能为空，且业务要求“NULL 视为独立分组”，需提前用 COALESCE(group_col, gen_random_uuid())（PostgreSQL）或 COALESCE(group_col, CONCAT('null_', ROW_NUMBER() OVER (ORDER BY ...))) 做兜底，避免多条 NULL 记录被错误合并到同一页。
- 测试前务必查文档确认目标数据库的
NULL分组规则 - 生产环境若无法控制源数据空值，建议在
PARTITION BY前加WHERE group_col IS NOT NULL过滤，比兜底更清晰 - SQLite 不支持窗口函数，这类需求需改用子查询模拟，性能和可读性都差很多
NULL 分组边界——这两个点一错，页码就全乱了。
