partition by本身不排名，真正排名的是row_number()、rank()或dense_rank()等窗口函数；它仅定义分组边界，必须与over()及order by配合使用，单独书写会报语法错误，且不改变行数。
直接说结论：PARTITION BY 本身不排名，它只是把数据切分成逻辑分区；真正做排名的是 ROW_NUMBER()、RANK() 或 DENSE_RANK() 这类窗口函数——PARTITION BY 只是告诉它们“在每个分组内独立计算”。
为什么 PARTITION BY 单独写没用？
PARTITION BY 是窗口函数的子句，不能独立使用。如果你写了 SELECT *, PARTITION BY dept_id，数据库会直接报错：ERROR: syntax error at or near "PARTITION"。
常见误操作：把 PARTITION BY 当成 GROUP BY 的替代品，结果发现字段没聚合、聚合函数报错、或者排序完全不对。
-
PARTITION BY不减少行数，每行都保留，只是“分组上下文”变了 -
GROUP BY会压缩行，必须搭配聚合函数；PARTITION BY必须搭配窗口函数 - 想按部门排工资名次？得写
ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC)
ROW_NUMBER() vs RANK() vs DENSE_RANK() 怎么选？
三者都依赖 PARTITION BY 和 ORDER BY，但并列处理逻辑不同——这直接影响业务含义。
-
ROW_NUMBER()：严格递增，相同值也强行给不同序号（比如 1,2,2,4） -
RANK()：跳号，并列后空出名次（比如 1,2,2,4 → 第三名被跳过） -
DENSE_RANK()：不跳号，并列后紧接下一个整数（比如 1,2,2,3）
示例场景：销售员按季度业绩排名。若两人同为 100 万，老板说“并列第二”，就得用 DENSE_RANK()；若 HR 系统要求唯一工号顺序，则用 ROW_NUMBER()。
ORDER BY 在窗口函数里为什么不能省？
PARTITION BY dept_id 只定义“谁跟谁比”，不定义“怎么比”。漏掉 ORDER BY 会导致结果不可预测，尤其在 PostgreSQL 或 SQL Server 中可能报错：window definition requires an ORDER BY clause。
- MySQL 8.0+ 允许省略
ORDER BY，但此时排序由引擎决定，每次执行可能不同 - 即使业务上“无所谓顺序”，也建议显式写
ORDER BY id或ORDER BY created_at保证确定性 - 复合排序很常见：比如先按
salary DESC，工资相同时按hire_date ASC防止随机抖动
性能和兼容性要注意什么？
窗口函数不是所有旧版本数据库都支持：PARTITION BY 在 MySQL 中仅 8.0+ 支持，SQLite 直到 3.25.0 才引入，而 SQL Server 2005 就已支持。
- 大数据量下，
ORDER BY字段最好有索引，否则OVER (PARTITION BY x ORDER BY y)可能触发全表排序 - 避免在
PARTITION BY中用表达式或函数（如PARTITION BY UPPER(dept_name)），会阻止索引下推 - Oracle 用户注意：
ROW_NUMBER()在 RAC 环境中若未指定唯一排序键，可能跨节点返回不同序号
最常被忽略的一点：分区键字段如果有 NULL，所有 NULL 会被归入同一个分区——这不是 bug，是标准行为，但常导致“明明没填部门的人也被排进去了”这类问题。
