MySQL中MD5()和SHA2()是单向哈希而非加密，适用于密码校验；需可逆时应选AES_ENCRYPT()；MD5已不安全，推荐SHA2(str, 256)；注意长度、索引及跨数据库兼容性。
MySQL里直接用MD5()和SHA2()函数加密字段？
能用，但不等于该用。这两个函数返回的是哈希值，不是可逆加密，本质是「单向摘要」——适合存密码校验，不适合保护需要还原的敏感数据（比如身份证号、手机号）。如果你真想“加密后还能解密”，得换AES_ENCRYPT()这类函数，而不是哈希。
常见错误现象：SELECT MD5('123') FROM dual; 看起来成功了，但一查表发现所有密码哈希值长度固定（MD5()是32位十六进制，SHA2('str', 256)是64位），且完全无法反推原文。有人误以为这是“加密”，结果导出数据时傻眼：连自己都读不懂。
-
MD5()已被证明不安全，碰撞成本极低，2020年后的新项目应避免用于密码场景 -
SHA2(str, 256)是当前MySQL默认推荐，但注意第二个参数必须是数字：224/256/384/512，写成字符串会报错ER_WRONG_ARGUMENTS - 哈希值默认是十六进制字符串，如果存到
VARCHAR字段，记得留够长度（如VARCHAR(64)对应SHA2(..., 256)）
PostgreSQL中digest()和hmac()怎么选？
PostgreSQL没内置MD5()函数名，而是统一用digest()，靠参数指定算法。它比MySQL更显式，但也更容易配错。
使用场景：你要做密码存储或接口签名验签。前者用digest(password, 'sha256')，后者若需密钥参与（比如Webhook签名），就得用hmac(data, key, 'sha256')——漏掉key参数就会得到完全不同的结果。
- 别写
digest('hello', 'md5')还指望和MySQL的MD5()输出一致：PostgreSQL的'md5'其实是MD5哈希后的base64编码，不是十六进制；要对齐MySQL，得用encode(digest('hello', 'sha256'), 'hex') -
hmac()的key参数类型必须是bytea，传普通字符串会报错function hmac(unknown, unknown, unknown) does not exist；稳妥写法是hmac('data', 'mykey'::bytea, 'sha256') - 性能上，
digest()比纯SQL拼接快，但比C扩展（如pgcrypto）慢；高并发生成令牌时，建议提前建好函数封装
SQLite里没有SHA2()怎么办？
SQLite原生只提供md5_hash()（需加载extension）和sha1_hash()（同理），SHA2系列压根没实现。强行要用，只有两个现实路径：升级到最新版+启用json1扩展（仍不支持），或在应用层处理。
最容易踩的坑是：有人写脚本用sqlite3命令行调SHA2()，结果报错 no such function: SHA2，然后花半天查文档确认——这函数真不存在。
- 如果只是开发测试且数据量小，用Python/Node.js在插入前算好哈希再写入，比折腾extension更省事
- 若必须SQL内完成，可用
substr(hex(sha1('x')), 1, 32)模拟MD5（不推荐，仅应急），但SHA256无法绕过缺失问题 - SQLite的
md5_hash()需要手动load extension：SELECT load_extension('./libsqlitefunctions.so');，不同系统路径和文件名差异大，上线前务必验证
哈希值比较时为什么=失效，而LIKE又慢？
因为哈希结果是二进制还是文本，直接影响索引是否生效。MySQL中MD5()返回VARCHAR，可以走B-tree索引；但PostgreSQL中digest()返回bytea，默认无法用=高效查询——你得显式转成text或加函数索引。
典型错误：在PostgreSQL里建表用hash BYTEA，然后写WHERE hash = '\x...'::bytea，看着能跑，但执行计划显示Seq Scan；换成WHERE encode(hash, 'hex') = 'abc123...'才走索引，代价却是每次查询都调一次encode()。
- MySQL：哈希字段用
VARCHAR(64)+COLLATE utf8mb4_bin，避免大小写混用导致匹配失败 - PostgreSQL：要么建表达式索引
CREATE INDEX idx_user_sha2 ON users ((encode(hash, 'hex')));，要么干脆存为TEXT类型 - SQLite：哈希字段必须定义为
TEXT，否则WHERE hash = ?可能因类型亲和性失效；且别信PRAGMA compile_options里带ENABLE_JSON就代表支持SHA2
哈希不是银弹，算法选择、字段类型、索引策略、甚至客户端连接的字符集，任何一个环节偏移一点，查出来的就是错的。实际部署前，拿真实数据跑一遍EXPLAIN或EXPLAIN QUERY PLAN，比读十篇文档都管用。
