MySQL的MD5()函数直接返回32位小写十六进制字符串，不可逆、无盐、不安全，仅适用于数据校验等低安全场景；输入NULL返回NULL，空字符串有确定哈希值，多字段拼接须用CONCAT()防隐式转换，存储推荐CHAR(32)。
MySQL中直接用MD5()函数生成32位十六进制摘要
MySQL内置MD5()函数最简单，传入字符串直接返回小写32位十六进制结果。注意它不接受NULL——传入NULL会返回NULL，不是空字符串或报错。
常见误用是想对密码加盐但直接拼接字符串：MD5('password' + 'salt')在MySQL里会触发隐式类型转换（把字符串当数字加），结果不可预期。正确写法是用CONCAT()：
SELECT MD5(CONCAT('mypassword', 'mysalt'));
另外，MD5()输出恒为32字符，固定长度，适合存入CHAR(32)字段，比VARCHAR略省空间且查询更快。
PostgreSQL需加载pgcrypto扩展并用md5()函数
PostgreSQL默认不带MD5函数，必须先启用扩展：CREATE EXTENSION IF NOT EXISTS pgcrypto;。之后才能用md5()（小写函数名，注意不是MD5()）。
它只接受TEXT类型输入，传BYTEA会报错function md5(bytea) does not exist。如果原始数据是二进制（比如从文件读取），得先转成文本或改用digest()函数：
-
md5('hello')→ 正确，返回'5d41402abc4b2a76b9719d911017c592' -
md5(E'\x68656c6c6f')→ 报错，不能直接传BYTEA -
encode(digest('hello', 'md5'), 'hex')→ 等效但更绕，一般没必要
SQL Server用HASHBYTES()且必须指定算法和输入编码
SQL Server没有MD5()别名，统一用HASHBYTES()，第一个参数是算法名字符串（'MD5'必须大写），第二个是VARBINARY输入。直接传VARCHAR会按当前数据库排序规则编码，容易出错。
典型陷阱：写HASHBYTES('MD5', 'abc')看似正常，但如果数据库是中文排序规则（如Chinese_PRC_CI_AS），字符串可能被当成UCS-2处理，结果和标准MD5不一致。安全写法是显式转码：
SELECT HASHBYTES('MD5', CONVERT(VARBINARY(8000), 'abc'));
返回值是VARBINARY(8000)，若要转成十六进制字符串，得套一层CONVERT：
SELECT CONVERT(CHAR(32), HASHBYTES('MD5', CONVERT(VARBINARY, 'abc')), 2);
所有数据库都该避免用MD5存储密码
MD5已被证实不抗碰撞、易被彩虹表破解，现代应用绝不能直接用MD5()存密码。即使加盐，也应选bcrypt、scrypt或argon2这类慢哈希算法。
SQL层做哈希仅适用于低安全场景，比如生成缓存键、校验文件完整性。一旦涉及用户凭证，哈希必须在应用层完成，且使用带工作因子的专用函数——数据库函数既没迭代次数控制，也没内存硬化机制。
另一个常被忽略的点：不同数据库对空格、换行、BOM的处理不一致。比如MD5('a
')在MySQL和PostgreSQL里结果相同，但在某些ODBC驱动下可能因行尾转换出错。生产环境建议统一在应用侧标准化输入再哈希。
