BigQuery 当前仅支持按天（DAY）进行时间分区，不支持按小时（HOUR）等更细粒度的分区；若尝试创建或写入按小时分区的表，实际将退化为非分区表或导致 _PARTITIONTIME 为空，查询时无法正确获取分区时间信息。
bigquery 当前仅支持按天（day）进行时间分区，不支持按小时（hour）等更细粒度的分区；若尝试创建或写入按小时分区的表，实际将退化为非分区表或导致 `_partitiontime` 为空，查询时无法正确获取分区时间信息。
在 BigQuery 中，时间分区表是提升查询性能与降低成本的重要机制，但其分区能力有明确限制：目前（截至最新稳定版 API）仅支持 DAY 粒度的时间分区。这意味着你无法创建真正意义上的“按小时分区”的原生分区表——所谓“hourly partitioned table”在 BigQuery 中并不存在。当你在表定义中指定 timePartitioning.type = "HOUR"（例如通过 API 或 CLI），BigQuery 将忽略该设置或直接报错，而不会静默创建小时级分区。
因此，你在查询中看到 _PARTITIONTIME 全为 NULL，根本原因在于：该表实际上并未成功创建为有效的时间分区表。即使你通过 Go 客户端库调用 InsertAll 写入数据，只要底层表未被正确定义为 DAY 分区表，所有写入数据都不会自动关联 _PARTITIONTIME，该伪列自然返回 NULL。
✅ 正确做法如下：
-
建表时显式指定 timePartitioning.type = "DAY"（推荐使用标准 SQL DDL）：
CREATE TABLE my_dataset.my_partitioned_table ( user_id STRING, event_time TIMESTAMP, action STRING ) PARTITION BY DATE(event_time) -- 按 event_time 字段的日期部分分区 OPTIONS( description = "Daily partitioned table based on event_time" );
⚠️ 注意：PARTITION BY _PARTITIONTIME 已弃用，应优先使用基于 TIMESTAMP/DATE 列的逻辑分区（即 PARTITION BY DATE(col)），它更可控、可预测，且支持 _PARTITIONDATE 伪列。
写入数据时无需特殊处理：只要表已正确定义为时间分区表，所有通过 insertAll、loadJob 或 writeStream 写入的记录，BigQuery 均会根据 event_time（或表定义中指定的分区字段）自动路由至对应日期分区，并填充 _PARTITIONTIME（对应 UTC 时间戳）或 _PARTITIONDATE（对应 YYYY-MM-DD 字符串）。
-
查询时正确引用伪列：
SELECT _PARTITIONDATE AS pd, -- 推荐：类型为 DATE，语义清晰 _PARTITIONTIME AS pt, -- 类型为 TIMESTAMP，值为当日 00:00:00 UTC
- FROM my_dataset.my_partitioned_table WHERE _PARTITIONDATE >= '2024-06-01' LIMIT 1000;
? 关键提醒：
- 不要依赖 _PARTITIONTIME 判断分区有效性——先验证表结构：运行 bq show --format=prettyjson project:dataset.table，确认输出中存在 "timePartitioning": {"type": "DAY"}；
- 若需小时级数据裁剪，可通过 WHERE EXTRACT(HOUR FROM event_time) = 14 配合 PARTITION BY DATE(event_time) 实现，既享受分区裁剪优势，又保留小时级过滤能力；
- 使用流式插入（Streaming Insert）写入分区表时，数据可能延迟 1–2 分钟才可见于 _PARTITIONTIME，且首分钟内写入的数据可能暂存于 __UNPARTITIONED__ 临时分区，属正常行为。
总结：BigQuery 的时间分区能力以 DAY 为唯一原生支持粒度。务必在建表阶段严格遵循官方规范，避免因误用 HOUR 等无效类型导致分区失效、伪列为空及后续查询逻辑错误。
