先说一个常见误区：很多人把 HASHBYTES 当成万能脱敏工具，对着手机号、身份证号就是一通哈希，觉得这样就安全了。但实际上，这根本不是脱敏，而是彻底把数据“毁”了——不可逆、无语义，业务方拿到一串乱码，既看不出是谁的号码，也没法做校验。真正意义上的脱敏，是在保留部分可读性的前提下隐藏敏感信息，比如 138****1234 这种形式。所以，别再把哈希当成脱敏来用了。
HASHBYTES 不是脱敏加密，而是哈希计算
直接用 HASHBYTES 对手机号、身份证号做“脱敏加密”，是个很经典的误解。它生成的是一串不可逆的二进制哈希值（比如 0x...），原始数据彻底丢失，根本没法还原。这不叫脱敏——脱敏的要求是可读性加部分隐藏，像 138****1234 那样。你真正需要的不是哈希，而是掩码表达式或者动态字符串处理。
为什么用 HASHBYTES 做脱敏会出问题
来看一个典型翻车场景：把用户手机号 '13812345678' 扔进 HASHBYTES('SHA2_512', @phone)，存下 64 字节二进制，再转成十六进制字符串——结果就是一堆毫无意义的天书。业务方压根不知道这是谁的号码，更别提信息校验、去重这些下游逻辑了。
- 哈希值长度固定（比如 SHA2_512 总是 64 字节），字段原有的格式和语义全丢了。
- 相同输入永远输出相同哈希，攻击者能用彩虹表反查常见手机号。
- 不加盐值的话，批量哈希可以被并行暴力破解；加了盐，同一号码每次哈希结果不一样，又失去了可比性。
HASHBYTES返回varbinary，直接 SELECT 显示成0x...，还得额外加一层CONVERT(VARCHAR, ..., 2)转换，纯属给自己增加工作量。
真正该怎么做：用表达式实现列级动态掩码
脱敏的正确姿势是在查询输出阶段下手，不改源数据，只改 SELECT 结果。SQL Server 里直接写一段掩码逻辑就行，比如：
SELECT id, LEFT(mobile, 3) + '****' + RIGHT(mobile, 4) AS mobile FROM users- 对 NULL 值要兜底：
ISNULL(LEFT(mobile, 3), '') + '****' + ISNULL(RIGHT(mobile, 4), '')。 - 身份证掩码中间 8 位：
LEFT(id_card, 6) + '********' + RIGHT(id_card, 4)。 - 如果字段名来自参数（比如
@col_name），必须用动态 SQL +sp_executesql，而且得提前校验字段是否在白名单里，防止注入。 - 复杂规则建议封装成标量函数，比如
f_mask_mobile(@mobile)，然后在 SELECT 里调用，便于复用和测试。
如果真要用 HASHBYTES，只适合密码类场景
只有当目标是“防明文落库”而且不需要还原的时候，哈希才派上用场——典型的就是密码存储。但即便是在密码场景，也得老老实实配合盐值和强算法：
- 盐值用
CRYPT_GEN_RANDOM(16)每用户独立生成，绝对不能复用。 - 算法选
'SHA2_256'或'SHA2_512'，'MD5'和'SHA1'直接拉黑。 - 哈希值和盐值必须分两列存储，别图省事拼在一列里。
- 验证时从库里取出盐值，再用相同算法重算哈希来比对，而不是去“解密”。
哈希的本质是单向校验，不是加密传输，更不是脱敏展示。如果搞混了这几个概念，合规审计的时候大概率会被直接打回。
