BigQuery 当前仅支持按天（DAY）粒度创建时间分区表，不支持按小时、分钟或秒分区；若尝试插入或查询假想的小时级分区表，_PARTITIONTIME 伪列将始终为 NULL，根本原因在于分区类型不被服务端认可。
bigquery 当前仅支持按天（day）粒度创建时间分区表，不支持按小时、分钟或秒分区；若尝试插入或查询假想的小时级分区表，`_partitiontime` 伪列将始终为 null，根本原因在于分区类型不被服务端认可。
在 BigQuery 中，时间分区表（Time-Partitioned Table）是优化查询性能与控制成本的重要机制，但其分区能力有明确限制：仅支持 DAY 粒度的时间分区（即 timePartitioning.type = "DAY"），不支持 HOUR、MONTH 或 YEAR 等其他粒度。这意味着：
- 创建表时若指定 HOUR 分区（如通过 API 错误配置 timePartitioning.type = "HOUR"），BigQuery 会静默忽略该设置，实际创建为未分区表或默认按天分区（取决于其他参数），导致 _PARTITIONTIME 伪列不可用或恒为 NULL；
- 即使数据写入逻辑（如 Go 客户端调用 TableUploader.Upload()）与非分区表完全一致，只要底层表未被正确定义为 DAY 分区表，_PARTITIONTIME 就不会自动填充；
- 查询中引用 _PARTITIONTIME 时，仅当表确为有效时间分区表（且为 DAY 类型）时，该伪列才返回对应分区日期（如 TIMESTAMP("2024-05-20")），否则返回 NULL。
✅ 正确做法如下：
-
建表时显式启用 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 = "Hourly ingestion, daily partitioned", require_partition_filter = TRUE );
⚠️ 注意：PARTITION BY TIMESTAMP_TRUNC(event_time, HOUR) 是无效语法——BigQuery 不支持小时级 TIMESTAMP_TRUNC 分区。唯一合法的时间分区表达式是 DATE(column) 或 TIMESTAMP_DATE(column)。
插入数据时无需特殊处理：只要目标表已正确定义为 DAY 分区，任何写入方式（Go SDK、bq CLI、UI 导入等）均会自动按 DATE(event_time) 归入对应分区，_PARTITIONTIME 自动设为该日期的零点时间戳（如 2024-05-20 00:00:00 UTC）。
-
查询时正确引用 _PARTITIONTIME：
SELECT _PARTITIONTIME AS partition_date, COUNT(*) AS row_count FROM `my_dataset.my_partitioned_table` WHERE _PARTITIONTIME >= '2024-05-20' GROUP BY _PARTITIONTIME;
✅ 此查询可利用分区裁剪（Partition Pruning），显著提升性能并降低成本。
? 验证分区状态：
SELECT table_name, partitioning_type, partition_expiration_days, require_partition_filter FROM `my_dataset.INFORMATION_SCHEMA.TABLES` WHERE table_name = 'my_partitioned_table';
若 partitioning_type 返回 NULL 或 DAY 以外的值，说明分区未生效。
? 总结：
BigQuery 的时间分区能力严格限定于 DAY 粒度，所谓“小时分区表”在技术上不存在。开发中应避免在建表配置中指定不支持的 HOUR 类型，而应通过 DATE() 函数结合高频率写入（如每小时一批）+ require_partition_filter = TRUE 实现逻辑上的小时级数据管理，并依赖 DAY 分区获得性能与成本优势。
