YugabyteDB中模拟BINARY(64)存储哈希密码的数据类型咨询

针对你需要存储64字节定长密码哈希值、插入环节随机生成salt的业务场景，选型方案如下：

• 最优方案：BYTEA类型+定长约束
  YugabyteDB的YSQL（PostgreSQL兼容）接口没有直接同名的BINARY(64)类型，BYTEA是原生二进制存储类型，语义和存储效率和SQL标准BINARY完全一致，只需要在建表时加64字节定长校验，就能100%等效BINARY(64)的行为，没有额外存储开销，也不会出现字符编码转换问题。
  建表示例：

  CREATE TABLE user_auth (
    user_id BIGINT PRIMARY KEY,
    pwd_hash BYTEA NOT NULL,
    -- 强制字段长度严格为64字节，和BINARY(64)的长度限制逻辑完全一致
    CONSTRAINT chk_pwd_hash_len CHECK (octet_length(pwd_hash) = 64)
  );
  

  不管是应用层计算完带salt的哈希值传原始二进制，还是调用YugabyteDB内置的加密函数生成哈希结果，都可以直接写入，密码校验时直接做二进制等值对比即可，性能最优。
• 备选方案：CHAR(128)类型（仅适配十六进制字符串存储场景）
  如果你现有业务逻辑是把64字节哈希值转成十六进制字符串再存储，可以用定长CHAR(128)，因为1字节二进制对应2个十六进制字符，64字节刚好对应128个字符长度。但这个方案比BYTEA多一倍存储空间，还需要额外加正则校验保证写入内容全为合法十六进制字符，没有特殊历史兼容需求不推荐用。

注意事项 #

• 不要用TEXT/VARCHAR类型存储原始二进制哈希值，会触发字符编码校验，存在非法字节报错的风险。
• 不要用无长度约束的二进制/字符串类型存储哈希值，会出现长度不符合要求的脏数据写入。
• 如果你用的是YCQL（Cassandra兼容）接口，直接使用原生BLOB类型搭配长度校验即可等效BINARY(64)。

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