直接用partition by后跟逗号分隔的列名（如partition by dept_id, region）实现多列分组排名，将组合值视为整体分组单位；order by仅控制组内排序，不影响分组维度。
SQL里怎么用多个字段做分组排名
直接说结论：用 PARTITION BY 后面跟逗号分隔的列名，就能实现多列分组排名。它不是“先按A排、再按B排”的嵌套逻辑，而是把（A, B）组合当成一个整体分组单位。
常见错误是写成 PARTITION BY col_a PARTITION BY col_b —— 这语法根本报错；也有人误以为加了 ORDER BY 就自动多维排序，其实 ORDER BY 只控制组内排序顺序，不影响分组维度。
-
PARTITION BY dept_id, region表示每个(dept_id, region)唯一组合各自独立计算排名 - 如果漏掉某个业务上必须隔离的维度（比如没加
year），会导致跨年数据混排，排名失真 - 注意 NULL 值：两个都为 NULL 的行会被划入同一分组（多数数据库行为），但若只有一列为 NULL，则不视为相同分组
ROW_NUMBER() / RANK() / DENSE_RANK() 在多列PARTITION BY下有什么区别
三者在多列分组场景下的行为完全一致——区别只在组内重复值的处理方式，和分组维度无关。关键看你要不要跳过重复名次。
比如销售表按 PARTITION BY region, quarter ORDER BY amount DESC：
-
ROW_NUMBER()：严格递增，哪怕金额相同也给不同序号（1,2,3…） -
RANK()：相同金额并列，但会跳过后续名次（1,1,3…） -
DENSE_RANK()：相同金额并列，不跳过（1,1,2…）
选哪个取决于业务定义：“并列第二”之后是叫“第三”还是“第四”。别因为用了多列分组就误以为函数行为会变。
为什么加了多列PARTITION BY后结果行数变少了
这不是排名函数的问题，而是你可能在 SELECT 中漏掉了 PARTITION BY 用到的列，又同时用了 GROUP BY 或去重逻辑（比如写了 SELECT DISTINCT），导致隐式聚合或过滤。
- 排名函数本身不减少行数，输入多少行，输出就是多少行（除非被 WHERE 过滤）
- 检查是否误把
PARTITION BY a, b和GROUP BY a混在一起用——这两者语义冲突 - 某些 BI 工具（如旧版 Tableau）在拖拽字段时会自动加聚合，表面看像排名出错，其实是前端做了二次处理
最简单的验证方式：单独跑一遍 SELECT *, ROW_NUMBER() OVER (PARTITION BY x, y ORDER BY z) AS rn FROM t，看行数是否和原表一致。
MySQL 8.0+ 和 PostgreSQL 多列PARTITION BY有兼容性问题吗
没有语法差异，PARTITION BY col1, col2, col3 在两者中完全通用。真正要注意的是窗口函数执行时机和 NULL 处理细节：
- MySQL 8.0.2+ 支持标准写法，但早期 8.0.0–8.0.1 有 bug，对多列 PARTITION BY 中含 NULL 的分组计算不准
- PostgreSQL 对
ORDER BY子句要求更严格：如果排序字段可能为 NULL，必须显式写ORDER BY col NULLS LAST，否则 NULL 会被排在最前，影响排名合理性 - SQL Server 同样支持，但注意它默认把 NULL 视为最小值，和 PG 相反
跨数据库迁移时，别只盯 PARTITION BY 本身，重点检查 ORDER BY 是否显式声明了 NULL 排序策略，这个点最容易在测试环境看不出问题，上线后数据异常。
