BigQuery列存储字符串长度对过滤、关联查询性能的影响

核心结论：字符串长度确实会对过滤、关联操作的性能产生影响，长度越长性能越差，差异大小取决于具体的查询场景和表的优化配置。

对不同操作的性能影响 #

• 过滤操作
  字符串等值过滤的耗时由两部分组成：列扫描IO开销、字符串匹配开销。长度越长，单条数据占用的存储空间越大，扫描相同行数需要读取的数据量越高，IO开销越大；同时等值匹配时需要对比的字节数更多，匹配耗时也会有微小上升。
  这种差异在需要全列扫描的场景下表现最明显：比如长度64的十六进制串单条占64字节，长度5的字符串单条占5字节，扫描1亿行时前者需要读取约6.4GB数据，后者仅需要读取500MB，查询耗时差异可达数倍。
  如果过滤列是表的分簇（Clustering）键，BigQuery可以在查询时直接跳过不匹配的存储块，仅需要对匹配块内的少量数据做对比，此时字符串长度带来的性能差异可以忽略。

• 关联（JOIN）操作
  字符串长度对关联操作的影响比过滤更明显。BigQuery做等值关联时，会先对关联键计算哈希值，再基于哈希值做匹配。字符串越长，单次哈希计算的耗时越高，同时哈希表的内存占用也越大，如果关联数据集过大，还可能触发磁盘溢出，进一步拉低性能。

针对示例场景的具体分析 #

示例中的查询语句：

SELECT time FROM abc.HackerNews.news where encrypted_data = 'abcdefghijklmnopqrstuvwxyz123deabcdefghijklmnopqrstuvwxyzabcde' LIMIT 1000

不同长度调整的性能变化：

1. 把encrypted_data从32位字符串改成64位：
   如果该列未配置分簇，查询耗时会上升30%~60%，表数据量越大涨幅越高；如果该列是分簇键，耗时涨幅不会超过10%，几乎感知不到差异。
2. 把encrypted_data从32位字符串缩短为5位：
   如果该列未配置分簇，查询性能会有明显提升，耗时可以降到原有水平的20%~50%；如果是分簇键，性能提升幅度在10%以内。

额外优化建议 #

如果你存储的是标准十六进制字符串，可以转成BYTES类型存储：64位十六进制串转成BYTES后仅占用32字节，能直接降低一半的存储和扫描开销，比单纯缩短字符串长度的收益更稳定。

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