BigQuery窗口函数在超大规模数据上默认不并行且易内存溢出，因按分区逐块加载至内存计算，不支持跨worker分片聚合；需前置过滤、分区裁剪与聚类索引协同优化，并优先选用ARRAY_AGG等替代方案。
BigQuery 中窗口函数在超大规模数据上默认不并行，且极易触发内存溢出或 shuffle 失败——这不是写法问题，而是执行模型限制。它不会像 PostgreSQL 那样尝试并行 WindowAgg，也不会自动 fallback 到磁盘排序；一旦单个分区数据量超过节点内存阈值（约 2GB），查询直接报 Resources exceeded。
为什么 ROW_NUMBER() OVER (PARTITION BY user_id) 在十亿行表里必崩
BigQuery 的窗口函数按分区逐块加载到内存中计算，不支持跨 worker 分片聚合。哪怕你只取 ROW_NUMBER() = 1，它仍需为每个 user_id 加载全部匹配行（可能数百万）再排序编号。常见错误现象包括：
Resources exceeded during query execution: The query could not be executed in the allotted memory- EXPLAIN 显示
Window节点的avg_bytes_per_row异常高，或estimated_bytes超过 1.5GB - 使用
RANGE BETWEEN时响应极慢，甚至超时（BigQuery 对 RANGE 支持弱，常退化为全分区扫描）
根本原因不是数据量大，而是分区粒度失控：user_id 基数太高（千万级），导致生成海量小分区，每个都触发独立排序开销；或某个 user_id 占比极高（数据倾斜），单分区就压垮内存。
必须前置过滤 + 分区裁剪 + 聚类索引三连击
BigQuery 不会优化窗口函数内部的扫描范围，WHERE 条件必须出现在窗口逻辑之前，且要能被分区/聚类识别。否则，WHERE 写在外层只会让窗口先算完再过滤，毫无意义。
- 用
PARTITION BY event_date替代PARTITION BY user_id：日期天然高基数、稳定、易裁剪，且 BigQuery 对时间分区支持最成熟 - 建表时指定
CLUSTER BY user_id, event_type，确保同一user_id的数据物理聚集，减少跨文件读取 - 过滤条件必须命中分区键和聚类键：例如
WHERE event_date = '2026-08-01' AND user_id IN UNNEST(['u1','u2'])，不能只写user_id = 'u1'（无法利用聚类） - 避免在窗口内用表达式：如
PARTITION BY DATE(created_at)会阻止分区裁剪，应改用已分区的字段event_date
替代方案比硬扛窗口更有效
当业务目标是“每个用户最新一条记录”或“Top-N”，强行用 ROW_NUMBER() 是最差选择。BigQuery 提供了更底层、更可控的替代路径：
- 用
ARRAY_AGG(STRUCT(*) ORDER BY created_at DESC LIMIT 1)[OFFSET(0)]：聚合函数天然支持分区裁剪，且不依赖全局排序，内存占用低一个数量级 - 对高频查询建物化视图（
MATERIALIZED VIEW）：预计算user_id → latest_order映射，查询直接走索引 - 拆成两步：先用
GROUP BY user_id找出每个用户的MAX(created_at)，再用JOIN回原表捞明细——只要user_id和created_at有联合索引，性能远超窗口 - 慎用
QUALIFY：虽然语法简洁，但它本质仍是窗口函数的语法糖，无法绕过内存限制，仅适合中小规模数据
UNNEST + 窗口必须加 PARTITION BY 业务主键
从 JSON 数组展开后直接套 ROW_NUMBER() OVER (ORDER BY price) 是典型陷阱。BigQuery 展开后所有子行混在一起，ORDER BY 变成全局排序，极易爆内存。
- 必须显式
PARTITION BY order_id（或其他父级唯一标识），确保排名限定在单个订单内 - 展开前先过滤：用
WHERE JSON_EXTRACT_ARRAY(items) IS NOT NULL排除空数组，避免生成无意义空行 - 用
SAFE.UNNEST()而非UNNEST()，防止某条记录 JSON 解析失败导致整个查询中断 - 别重复解析：如果多次用到
JSON_EXTRACT_SCALAR(items, '$.price')，先用SELECT ..., JSON_EXTRACT_ARRAY(items) AS item_arr提取一次，再在UNNEST(item_arr)后引用字段
真正卡住的从来不是语法会不会写，而是没意识到 BigQuery 的窗口函数根本不设计用于单分区百万行以上的场景——它靠的是结构化预处理，不是运行时硬算。
