PARTITION BY 不是 GROUP BY 的替代写法，它不聚合、不删行，只定义计算边界；漏写或字段选错会导致窗口函数在错误范围内计算，如 PARTITION BY order_id 使每行独立成窗，SUM 变原值、RANK 全为 1。
PARTITION BY 写错会导致分组结果完全失真
直接说结论：PARTITION BY 不是 GROUP BY 的替代写法，它不聚合、不删行，只定义“计算边界”。一旦字段选错或漏写，窗口函数就会在错误的逻辑范围内计算——比如想按用户统计，却写了 PARTITION BY order_id，结果每行都变成独立窗口，SUM() 变成原值，RANK() 全是 1。
哪些字段适合放进 PARTITION BY
核心判断标准：这个字段的取值变化，是否意味着“统计上下文重置”？
- 用户行为分析中，
user_id是天然分组字段：每个用户的点击、下单、支付应各自独立累计 - 设备监控场景下，
device_id或resource_key才是正确分组依据，而不是时间戳或状态码 - 误用
PARTITION BY created_at::date做日维度统计？不行——这会把同一天所有用户混在一起算，失去用户粒度 - 多字段组合常见但易错：如
PARTITION BY region, product_category，注意顺序不影响结果，但缺失任一都会扩大窗口范围
ORDER BY 和 PARTITION BY 的配合陷阱
PARTITION BY 定义“谁跟谁比”，ORDER BY 决定“怎么比”。两者缺一不可（对排序类函数如 ROW_NUMBER()、RANK()），但对纯聚合类如 SUM() OVER (PARTITION BY x)，ORDER BY 反而会引入非预期行为。
- ✅ 正确：统计每个用户的总消费额 →
SUM(amount) OVER (PARTITION BY user_id) - ❌ 错误：加了
ORDER BY created_at→ 变成“截止当前订单的时间累计和”，不是静态总额 - ⚠️ 隐患：MySQL 8.0 默认使用
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，若ORDER BY字段含重复值（如多个订单同秒创建），窗口可能意外包含更多行 - ? 稳定性补救：当
ORDER BY字段可能重复时，追加主键或唯一字段，如ORDER BY created_at DESC, id DESC
实际执行前必须验证的三件事
别等上线才发现分组错了。执行前快速确认：
- 查
COUNT(*) OVER (PARTITION BY your_field)，看最大值是否符合预期（比如用户表里某user_id出现 500 次，但你只预期最多 100 次，说明数据异常或分组字段不对） - 用
SELECT DISTINCT your_field FROM table看分组键取值是否合理，有无大量 NULL 或空字符串干扰分区 - 小样本测试：抽一条记录，手动查它所属分组的所有原始行，确认这些行确实属于同一业务逻辑单元（例如同属一个用户、一台设备、一个门店）
最常被忽略的是 NULL 值处理——PostgreSQL 默认把 NULL 当最小值排序，SQL Server 可能视为最大值，不同库行为不一致，但 PARTITION BY 本身会把所有 NULL 归为同一组，这点反而稳定。真正要盯紧的，是业务上“NULL 是否代表有效分组单位”。
