在SQL Server中实现MD5加密，本质上不是调用加密函数，而是计算消息摘要。HASHBYTES函数从SQL Server 2008开始提供，可以直接在T-SQL中对字符或二进制数据执行哈希运算。它支持MD2、MD4、MD5、SHA、SHA1、SHA2_256、SHA2_512等算法，其中MD5使用最为普遍的一种场景就是用户密码摘要存储和文件内容校验。与单纯的加密不同，MD5是不可逆的，只能由原文生成摘要，无法从摘要还原原文，这也正是很多系统用它保存敏感字段的原因。
一、HASHBYTES函数基础与MD5输出格式
HASHBYTES函数的语法并不复杂，两个参数分别是算法名称和输入值。算法名称需要用单引号括起来，常用的写法是'MD5'。输入值可以是VARCHAR、NVARCHAR或VARBINARY类型，函数返回VARBINARY类型的结果。对于MD5算法来说，返回结果固定是16字节，也就是128位。很多开发人员刚接触时会把16字节理解成16位十六进制字符串，实际转换成十六进制文本后长度是32个字符。下面的查询可以直接看到原始二进制和文本形式的结果：
SELECT
HASHBYTES('MD5', N'123456') AS OriginalHash,
CONVERT(VARCHAR(32), HASHBYTES('MD5', N'123456'), 2) AS HexHash;
CONVERT的第三个参数2表示把二进制转换成不带0x前缀的十六进制字符串。SQL Server还有sys.fn_varbintohexstr函数，但它返回的结果带有0x前缀，不利于直接存储到字符列中。如果希望统一使用小写形式，可以再套一层LOWER函数；如果希望用大写展示，可以套用UPPER函数。MD5本身对大小写不敏感，因为十六进制只是表示方式，底层二进制值完全相同。
需要特别注意的是输入字符串的类型会直接影响哈希结果。VARCHAR类型按照数据库排序规则的代码页解释字节，而NVARCHAR类型按照UTF-16编码解释字节。同一个字符串在这两种类型下计算出的MD5可能完全不同。如果应用层使用UTF-8或ASCII编码生成MD5，而数据库使用NVARCHAR，两边结果对不上，问题往往就出在编码方式不统一。建议在项目开始阶段明确约定：要么统一用NVARCHAR，要么统一在应用层先把字符串转为固定编码的字节数组再传入数据库比较。
二、用户密码摘要存储的完整实现
如果要在表中保存用户密码摘要，字段类型不建议设置成字符型。虽然32位十六进制字符串可读性更好，但会多占用至少32字节空间，而VARBINARY(16)只占用16字节。对于百万级用户表，空间差异会被放大，而且二进制比较速度也更快。建表时可以这样定义：
CREATE TABLE Users (
UserID INT IDENTITY(1,1) PRIMARY KEY,
UserName NVARCHAR(50) NOT NULL,
UserSalt UNIQUEIDENTIFIER NOT NULL DEFAULT NEWID(),
PasswordHash VARBINARY(16) NOT NULL
);
写入数据时直接调用HASHBYTES即可，不需要在应用层先算一遍。这样做的好处是原始密码不会通过网络传输到应用服务器再返回数据库，减少了一个暴露环节。不过如果需要支持应用层与数据库层共用同一套摘要逻辑，也可以把计算放在应用层，然后在SQL Server中只做比较。两种方式没有绝对优劣，关键看架构中数据库和应用层的职责边界。
仅对密码做MD5仍然存在彩虹表风险，常用的缓解手段是加盐。盐可以是UNIQUEIDENTIFIER、随机字符串或用户创建时间，只要每个用户不同且不可预测就能显著增加破解难度。下面示例先声明盐值，再把盐和密码拼接后计算摘要：
DECLARE @UserName NVARCHAR(50) = N'zhangsan';
DECLARE @Password NVARCHAR(50) = N'123456';
DECLARE @Salt UNIQUEIDENTIFIER = NEWID();
INSERT INTO Users (UserName, UserSalt, PasswordHash)
VALUES (@UserName, @Salt, HASHBYTES('MD5', CAST(@Salt AS NVARCHAR(36)) + @Password));
验证登录时，只需要根据用户名和输入的密码重新计算一次哈希，再与表中的值比较即可。示例查询如下：
DECLARE @InputUserName NVARCHAR(50) = N'zhangsan';
DECLARE @InputPassword NVARCHAR(50) = N'123456';
SELECT UserID, UserName
FROM Users
WHERE UserName = @InputUserName
AND PasswordHash = HASHBYTES('MD5', CAST(UserSalt AS NVARCHAR(36)) + @InputPassword);
三、查询匹配、索引与性能细节
密码验证场景通常先根据用户名定位到一行，再比较哈希值。如果表中用户数量很大，最好在UserName列上建立唯一索引或主键，避免全表扫描。因为HASHBYTES函数作用在列上时无法利用索引，数据库只能对每一行先计算哈希再和输入值比较。把高选择性的条件放在前面，才能让查询计划先通过索引锁定目标行。
如果要频繁按照哈希值查询，例如判断某个文件指纹是否已存在，可以增加一个持久化计算列并建立索引。示例可以先通过触发器或计算列保存HASHBYTES结果到独立的VARBINARY列，再在该列上创建索引。但这种方案在写入时会增加少量CPU开销，适合读取远多于写入的业务表。对于用户密码这种低频验证场景，通常不需要专门为密码哈希建立索引。
另一个容易忽略的细节是HASHBYTES遇到NULL会直接返回NULL。如果密码列允许NULL，在比较时NULL = NULL的结果不是真，可能导致合法用户也无法登录。建表时应把相关字段设为NOT NULL，或者在计算哈希前用ISNULL处理空值。从设计规范看，密码摘要列不应当有NULL值。
四、MD5的安全局限与替代算法
MD5在设计之初就不是为了高强度密码存储而生的，它更侧重于快速生成摘要。随着计算能力提升，MD5碰撞已经被实际构造出来，也就是说不同输入可能产生相同的哈希值。虽然这种碰撞对普通登录场景的直接影响有限，但如果系统涉及支付、政务、金融等高安全等级业务，继续使用MD5保存密码并不合适。安全领域更推荐使用SHA2_256或bcrypt等算法。
SQL Server的HASHBYTES同样支持SHA2_256和SHA2_512，调用方式与MD5几乎一致，只是算法名称替换成'SHA2_256'，返回长度分别为32字节和64字节。代码迁移成本很低：
SELECT
HASHBYTES('SHA2_256', N'123456') AS SHA256Hash,
HASHBYTES('SHA2_512', N'123456') AS SHA512Hash;
除了算法选择，还建议在应用层加入慢哈希方案，例如PBKDF2、bcrypt或argon2。SQL Server本身没有内置这些算法，但可以调用CLR函数或通过外部程序完成。如果必须在纯T-SQL环境里实现，可以考虑对HASHBYTES进行多轮迭代，但这会消耗大量CPU，实际收益不如直接使用专门的密码哈希库。对于现有旧系统，如果短期无法替换，至少应当加上固定盐和动态盐，并规划好升级路径。
总的来说，HASHBYTES为SQL Server提供了便捷的MD5摘要能力，适合数据校验、快速指纹生成和旧系统兼容。用于用户密码存储时，要明确编码规则、注意NULL值、设计合理的盐方案，并优先考虑SHA2_256或更强的替代算法。只有把哈希函数的特性、存储类型和查询索引结合起来，才能在实际项目中既满足效率又控制安全风险。
SQL ServerMD5加密HASHBYTES函数修改时间：2026-09-24 06:33:24