PARTITION BY 多字段组合合法但不等于多维聚合，仅定义复合分组键；须确保字段有业务层级关系、避免高基数冗余字段，并配合CLUSTER BY优化物理存储，否则窗口函数易退化或性能暴降。
PARTITION BY 多字段组合的语法和语义陷阱
直接写 PARTITION BY region, product_type, stat_date 是合法的，但不等于“同时聚合多个维度”——它只是定义了一个复合分组键，SQL 会把三者值完全相同的行归为一组。关键在于：这个组合是否真实存在业务意义？比如 stat_date 是日期，region 是大区，product_type 是品类，三者联合确实能定位到一个明确的业务单元；但如果混入高基数字段如 user_id，那每组平均只有一两行，窗口函数就退化成无意义的单行计算。
常见错误现象：COUNT(*) OVER (PARTITION BY user_id, stat_date) 看似在算“用户日活”，实则因 user_id 唯一性太强，结果全是 1，无法反映真实聚合意图。
- 必须确认字段间有层级或共现关系（如
tenant_id→region→store_id） - 避免把时间粒度差异大的字段硬凑（如
PARTITION BY year, day，day已隐含年份，冗余且易出错） - 字符串字段注意大小写和空格，
PARTITION BY TRIM(UPPER(region))比裸写region更稳
Snowflake 中多维 PARTITION BY 的性能雷区
Snowflake 不会对 PARTITION BY 字段自动建索引，物理存储是否聚簇才是性能命门。哪怕你写了 PARTITION BY tenant_id, stat_date, region，如果表没按这三者 CLUSTER BY，查询时仍要扫描大量微分区。
典型错误：在亿级日志表上执行 SUM(amount) OVER (PARTITION BY user_id, stat_date)，耗时从 200ms 暴涨到 15s —— 并非函数慢，而是数据物理分散导致 I/O 爆炸。
- 建表时优先用低基数、高频过滤字段做
CLUSTER BY，如CLUSTER BY (stat_date, tenant_id) - 对已存在表，运行
ALTER TABLE logs RECLUSTER触发重组织（默认每 24 小时自动一次，但手动触发更可控） - 别把
user_id放进CLUSTER BY主位；它适合做PARTITION BY的补充，而非主干
多维度累计指标必须拆成独立窗口函数
想在一个 SUM() OVER 里用 CASE WHEN 同时算“高客单订单数”和“总订单数”，是典型反模式。Snowflake 优化器无法并行处理这种嵌套条件窗口，实际执行比拆成两个独立窗口慢 3–5 倍。
正确写法是每个指标单独开窗，用相同 PARTITION BY 和 ORDER BY 结构：
SELECT region, stat_date, product_type, COUNT(*) OVER (PARTITION BY region, stat_date ORDER BY product_type ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS cum_total_orders, COUNT(CASE WHEN amount > 500 THEN 1 END) OVER (PARTITION BY region, stat_date ORDER BY product_type ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS cum_high_value_orders FROM sales;
- 两个窗口共享
PARTITION BY和ORDER BY，物理扫描只需一次 -
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW是累计唯一可靠写法，RANGE在 NULL 或重复值时漏算 - 不要省略
ORDER BY—— 即使业务不要顺序语义，也得写ORDER BY 1让 Snowflake 跳过全局排序
如何验证多维 PARTITION BY 是否真生效
最直接的办法是加个 COUNT(*) OVER (PARTITION BY ...) 辅助列，看结果分布。如果某组计数恒为 1 或极小（如全表 1 亿行，但 99% 的组计数 ≤ 3），说明分组粒度过细，要么字段选错，要么数据稀疏。
另一个信号是执行计划里出现 “WindowAggregate: Partitioned by [x,y,z]” 后紧跟着 “Sort” 节点——这意味着 Snowflake 正在为你补排序，而你本意可能并不需要它。
- 用
EXPLAIN查看物理执行计划，重点找 “Sort” 是否出现在窗口节点前 - 对比加
ORDER BY 1和不加的执行时间，差距超过 2 倍就说明原写法触发了隐式全局排序 - 对高基数字段，先用
SELECT COUNT(DISTINCT field)估算唯一值数量，再决定是否纳入PARTITION BY
PARTITION BY 不是字段堆砌，而是对业务切片逻辑的显式编码。最容易被忽略的，是物理存储与逻辑分组之间的断层——再正确的 SQL 写法，遇上散乱的数据布局，照样慢得不可接受。 
