ROW_NUMBER()必须配合PARTITION BY和ORDER BY才能实现多列组合分组编号；单独使用仅全局编号，无法体现组合唯一性；漏写PARTITION BY会导致编号连续无分组，且NULL值分组行为因数据库而异，需用COALESCE等预处理。
ROW_NUMBER() 必须配合 PARTITION BY 和 ORDER BY 才能按多列组合分组编号
单独写 ROW_NUMBER() 不会自动识别“多列组合”，它本身不接受列列表作为参数，必须靠 PARTITION BY 明确分组依据、ORDER BY 明确组内排序逻辑。否则所有行会被当成一个大组连续编号，达不到“每组独立从 1 开始”的效果。
常见错误是只写 ORDER BY col1, col2 而漏掉 PARTITION BY，结果看似有序，实则编号全局连续，无法体现“组合唯一性”。
-
PARTITION BY col_a, col_b：把(col_a, col_b)值完全相同的行划为一组 -
ORDER BY col_c DESC, id ASC：组内按col_c降序、再按id升序排，决定编号先后 - 分组字段和排序字段可以不同；但
PARTITION BY不能为空（否则等价于不分组）
多列组合去重后编号，不能直接用 DISTINCT + ROW_NUMBER()
DISTINCT 发生在逻辑查询处理顺序的早期阶段，而窗口函数如 ROW_NUMBER() 在 SELECT 阶段才执行。如果写成 SELECT DISTINCT ..., ROW_NUMBER() OVER (...)，数据库会先去重再编号，但编号依据的是去重后的临时结果集——这会导致原表中本属于同一组合的多行被压缩，编号丢失原始行上下文。
正确做法是先用 GROUP BY 或子查询聚合，或直接在原表上用 PARTITION BY 处理：
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY category, status
ORDER BY created_at DESC, id ASC
) AS rn
FROM orders;
这样每条原始记录都保留，并获得其所在 (category, status) 组内的序号。
当组合字段含 NULL 时，ROW_NUMBER() 的分组行为要特别注意
SQL 标准中，NULL = NULL 为未知（UNKNOWN），所以 PARTITION BY col1, col2 遇到 (NULL, 'A') 和 (NULL, 'A') 会被视为同一组；但 (NULL, 'A') 和 (NULL, NULL) 是否同组，取决于具体数据库实现（PostgreSQL 和 SQL Server 认为 NULLs 相等并归为一组，MySQL 8.0+ 默认也如此，但旧版本或特定模式下可能不同）。
若业务要求严格区分 NULL 的语义，建议提前用 COALESCE(col, '__MISSING__') 或 CASE WHEN col IS NULL THEN -1 ELSE col END 做标准化处理，避免分组意外合并：
ROW_NUMBER() OVER ( PARTITION BY COALESCE(dept_id, -999), COALESCE(team_code, 'N/A') ORDER BY updated_at DESC ) AS seq
性能敏感场景下，PARTITION BY 字段必须有合适索引
ROW_NUMBER() 的开销主要来自排序——数据库需对每个分区内部做局部排序。如果 PARTITION BY 的列基数高（比如千万级用户表按 user_id 分组），或 ORDER BY 列无索引，执行计划容易退化为磁盘排序（Spill to TempDB / disk-based sort），大幅拖慢响应。
优化方向很直接：
- 确保
PARTITION BY列（或其前缀）上有索引，例如(category, status, created_at)覆盖分组+排序需求 - 避免在
ORDER BY中使用函数表达式（如UPPER(name)），否则索引失效 - 若只需“每组取第 1 行”，优先考虑
NOT EXISTS或GROUP BY + MIN(id)，比全量编号再过滤更高效
真正需要逐行编号时，别省略索引设计这步——它不是锦上添花，而是防止查询从秒级变成分钟级的关键。
