Google BigQuery中仅需固定3种取值的列应使用什么数据类型？

针对你提出的“仅允许r/g/b三个单字符取值的列该选什么类型”的问题，核心结论非常明确：在BigQuery里STRING是没有任何替代方案的最优选择，完全不需要因为“STRING是变长类型”的固有认知犹豫。

为什么其他看起来“更合适”的选型全是坑 #

很多从传统数据库转BigQuery的用户，第一反应会想找更“节省空间”的替代方案，实际上这些方案在BigQuery场景下全是负收益：

• 用整数做映射存值（比如用INT64存1代表r、2代表g、3代表b）：这类设计是传统OLTP库的常见操作，但在BigQuery这种分析型数仓里纯亏。一方面写分析SQL的时候每次都要写CASE WHEN转换、或者额外关联映射表，可读性和可维护性极差；另一方面BigQuery对低基数重复值的列存压缩效率非常高，单字符重复字符串经过字典压缩、游程编码后的实际存储体积，比等价的INT64列还要小，根本不存在“整数更省空间”的优势。
• 用BYTES类型存单字节值：完全没有业务可读性，查询出来的结果是原始二进制值，每次用都要转码，没有任何实用价值。
• 找类似传统库的定长CHAR(1)类型：BigQuery从设计层面就没有拆分定长/变长字符串的逻辑，所有字符串统一使用STRING存储，就算你在DDL里写类似CHAR(1)的定义，实际的存储结构、查询性能和STRING完全没有差异，根本不存在“定长比变长省空间”的区别。

STRING为什么是真正的最优解 #

1. 完全适配BigQuery的存储优化逻辑：单字符长度的短字符串是BigQuery列存中压缩效率最高的字段类型之一，针对这种全列只有3个重复值的低基数场景，压缩效果可以直接把单字段的存储成本压到极低。你担心的“变长字符串有额外开销”的问题在这个场景根本不存在——因为这列所有值最长也就1个字符，BigQuery的短字符串优化逻辑会直接把值内嵌到列存块里，没有传统库变长字段的额外指针、长度字段开销。
2. 取值限制可以通过schema层面的约束实现，根本不需要靠数据类型锁范围：建表时直接搭配CHECK约束从底层锁死合法取值，不需要在ETL流程里写重复的校验逻辑，示例DDL：

CREATE TABLE your_project.your_dataset.your_table (
  row_id INT64,
  color_code STRING NOT NULL,
  -- 从表结构层面强制仅允许三个合法取值
  CONSTRAINT valid_color CHECK (color_code IN ('r', 'g', 'b'))
)

3. 分析场景的效率拉满：查询出来的结果直接就是业务可读的r/g/b值，不需要做任何二次转换，不管是做维度聚合、透视分析，SQL编写的复杂度远低于数字映射的方案。

补充说明 #

BigQuery目前没有原生的ENUM枚举类型，业内针对“固定少量取值范围的低基数列”的通用最佳实践，就是用STRING搭配CHECK约束，不存在更“高级”的替代方案。

内容的提问来源于stack exchange，提问作者sia