BigQuery 当前仅支持基于日期的 DAY 类型时间分区，不支持 HOUR、MONTH 或 YEAR 等其他粒度；若尝试创建或写入按小时分区的表，系统将忽略分区逻辑，导致 _PARTITIONTIME 伪列为 NULL，查询时无法按预期利用分区裁剪。
bigquery 当前仅支持基于日期的 day 类型时间分区，不支持 hour、month 或 year 等其他粒度；若尝试创建或写入按小时分区的表，系统将忽略分区逻辑，导致 `_partitiontime` 伪列为 null，查询时无法按预期利用分区裁剪。
在 BigQuery 中，时间分区表（Time-Partitioned Table）是优化查询性能与控制成本的关键机制，但其分区类型有严格限制：仅支持 DAY 粒度的时间分区（即按 TIMESTAMP 或 DATE 列自动按日切分）。你遇到 _PARTITIONTIME 全为 NULL 的问题，根本原因在于：BigQuery 不支持 HOUR 级别的原生时间分区——无论建表时指定 timePartitioning.type = "HOUR"（该值非法），还是通过 API 尝试写入带小时精度的分区数据，系统均会静默降级或失败，最终导致分区元信息缺失。
✅ 正确做法如下：
-
建表时明确指定 DAY 分区（推荐使用标准 SQL DDL）：
CREATE TABLE `my_dataset.my_partitioned_table` ( event_id STRING, user_id INT64, event_time TIMESTAMP ) PARTITION BY DATE(event_time) -- ✅ 按 event_time 的日期部分分区 CLUSTER BY user_id;
写入数据时无需手动指定分区：只要 event_time 字段为 TIMESTAMP 类型且非 NULL，BigQuery 会自动根据其日期部分（如 '2024-05-20'）路由到对应分区，并正确填充 _PARTITIONTIME（值为 TIMESTAMP('2024-05-20')）。
-
查询时可安全引用 _PARTITIONTIME：
SELECT _PARTITIONTIME AS pt, event_id, user_id FROM `my_dataset.my_partitioned_table` WHERE _PARTITIONTIME >= '2024-05-20' -- ✅ 自动触发分区裁剪 LIMIT 1000;
⚠️ 注意事项：
- _PARTITIONTIME 是伪列，仅对 TIMESTAMP/DATE 类型的 PARTITION BY DATE(...) 表有效；若使用整数分区（如 _PARTITIONDATE 对应 DATE 分区），请勿混用。
- Go 客户端库（cloud.google.com/go/bigquery）写入时，确保传入的 RowInsertion 数据中 event_time 字段为 time.Time 类型且含时区信息（推荐 UTC），避免因解析失败导致分区丢失。
- 若需更高频次的数据组织（如每小时汇总），可采用 分区 + 集群（Clustering） 组合策略：按天分区后，再对 HOUR(event_time) 或 FORMAT_TIMESTAMP('%H', event_time) 进行聚簇，兼顾查询效率与粒度灵活性。
总结：放弃 HOUR 分区幻想，拥抱 DAY 分区 + 合理聚簇设计，才是 BigQuery 生产环境的最佳实践。
