ROW_NUMBER()为何是分组页码的首选函数呢？原因在于它通过PARTITION BY能实现每组从1开始的连续自然编号。而RANK()和DENSE_RANK()呢，由于其重复值处理机制的缘故，会致使页码不连续。并且，ROW_NUMBER()必须配合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 分组边界——这两个点一错，页码就全乱了。