DB2 LUW v11.5中BINARY与CHAR FOR BIT DATA数据类型该如何选择？

在DB2 LUW v11.5中，BINARY和CHAR FOR BIT DATA虽都能存储原始二进制数据，但存在易被忽略的差异，这些差异决定了不同场景下的选择倾向：

核心差异点 #

• 类型语义归属

  • BINARY是原生二进制数据类型，定义上明确用于存储无解释的字节序列，属于二进制类型体系。
  • CHAR FOR BIT DATA是字符类型的变种，本质是将字符串强制按二进制处理，语义上偏向“被当作二进制的字符串”。

• 填充行为不同

  • BINARY(n)存储时，若数据长度小于n，会用十六进制0x00填充至指定字节长度。
  • CHAR(n) FOR BIT DATA则用**空格字符（0x20）**填充，这是字符类型的遗留特性。如果你的二进制数据不能包含0x20填充值，这一点需要重点关注。

• 兼容性与迁移成本

  • BINARY是通用数据库二进制类型，在Oracle、SQL Server等其他数据库中有直接对应类型，后续迁移成本更低。
  • CHAR FOR BIT DATA是DB2特有的语法，其他数据库无直接匹配类型，迁移时需要额外转换处理。

• 函数与操作逻辑

  • 部分字符串函数对CHAR FOR BIT DATA的处理更贴近字符类型逻辑，而BINARY仅支持二进制相关函数操作。例如字符串拼接时，CHAR FOR BIT DATA会保留空格填充，BINARY则严格按字节拼接。
  • 两者的排序、比较均按字节值执行，但CHAR FOR BIT DATA的比较逻辑继承自字符类型，语义上与BINARY有细微区别。

选择建议 #

• 新开发系统优先选BINARY：语义清晰，避免字符类型填充带来的潜在问题，符合通用数据库设计规范。
• 维护旧系统或兼容原有结构时选CHAR FOR BIT DATA：如果原有表结构依赖该类型，或需要使用其字符类型相关的函数行为，可继续沿用。
• 补充：若二进制数据长度不固定，更推荐使用VARBINARY或VARCHAR FOR BIT DATA，灵活性更高。

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