窗口函数比JOIN聚合快，因Snowflake向量化引擎优化单次有序扫描，而JOIN需哈希匹配和回填维度字段，引发数据移动与物化；标量子查询降级为嵌套循环，自连接呈N²复杂度，窗口函数仅需一次排序+并行编号。
直接用窗口函数替代标量子查询或自连接，能避免多次扫描事实表，尤其在宽表+高频聚合场景下，性能提升常达3–5倍。但前提是写法得对，否则可能更慢。
为什么Snowflake里窗口函数比JOIN聚合快
Snowflake的向量化执行引擎对单次有序扫描做了深度优化，而窗口函数天然就是“一次读、分区排、内存算”。反观先JOIN再GROUP BY，会触发：① 两个大表哈希匹配（可能溢出到磁盘）；② 聚合后还要回填维度字段——这两步都绕不开数据移动和中间结果物化。
- 标量子查询如
(SELECT MAX(amount) FROM orders o2 WHERE o2.user_id = u.id)在Snowflake中会被降级为nested loop，每行都重扫orders表 - 自连接求“每个用户最新订单”需
JOIN orders o1 ON o1.user_id = o2.user_id AND o1.created_at > o2.created_at，实际是N²复杂度 - 窗口函数
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)只需一次排序+滑动编号，且能利用虚拟仓库的并行分片能力
必须显式写ORDER BY，否则Snowflake会强制全局排序
Snowflake不支持无序窗口计算。哪怕你只想要 COUNT(*) OVER (PARTITION BY tenant_id)，如果没写 ORDER BY，它仍会按 tenant_id 全局排序——这对亿级日志表是灾难性的。
- 正确写法：
COUNT(*) OVER (PARTITION BY tenant_id ORDER BY event_time)，哪怕event_time只是占位，也比不写强 - 若真不需要排序语义，用
ORDER BY 1（常量）可跳过排序逻辑，但仅限于COUNT/AVG等不依赖顺序的聚合 - 注意：Snowflake的
RANGE BETWEEN对NULL值默认跳过，而ROWS BETWEEN会保留NULL行位置，选错会导致累计值偏移
复合索引无效？Snowflake不用传统B-Tree索引
Snowflake没有传统意义上的索引，它靠微分区（micro-partition）自动剪枝。所以你建 CREATE INDEX ON orders(tenant_id, created_at) 是无效操作，会报错。
- 真正起作用的是CLUSTERING KEY：比如
CLUSTER BY (tenant_id, created_at)，它让数据物理上按这两列排序存储，极大加速PARTITION BY tenant_id ORDER BY created_at的窗口计算 - CLUSTERING KEY不是建完就生效，需运行
ALTER TABLE orders RECLUSTER或等自动维护（默认每24小时） - 高基数字段如
user_id不适合做CLUSTERING KEY主列，优先选tenant_id、region、DATE(event_time)这类中低基数+业务强过滤字段
STRING_AGG + ORDER BY拼接时截断风险
Snowflake的 STRING_AGG() 默认无长度限制，但如果你从其他数据库迁移SQL，容易忽略MySQL/PostgreSQL的隐式截断行为——而在Snowflake里，超长拼接会直接报错 Expression overflow。
- 安全写法：
STRING_AGG(col, ', ' ORDER BY sort_col) LIMIT 10000，用LIMIT控制输出长度 - 若需拼接超万字符，改用
ARRAY_AGG()+ARRAY_TO_STRING()组合，它们对大对象更友好 - 注意：Snowflake中
STRING_AGG()不去重，重复值会原样拼入，必要时先套一层DISTINCT子查询
最易被忽略的一点：Snowflake的窗口函数在CTE里不能复用同一个WINDOW定义——它不支持SQL:2016的WINDOW子句语法。每次调用都得重写完整的 OVER (PARTITION BY ... ORDER BY ...)，别指望像PostgreSQL那样用 WINDOW w AS (...) 省事。
