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，比读十篇文档都管用。
