md5() 和 sha2() 是单向哈希函数，不可逆；aes_encrypt()/aes_decrypt() 才支持可逆加解密，但需严格匹配密钥长度、模式（如 aes-256-cbc）、iv 及二进制处理流程。
mysql 里 MD5() 和 SHA2() 是单向哈希，不能“解密”
很多人想用 MD5() 或 SHA2() 存密码，再“反查”原始值——这做不到。它们是单向散列函数，设计目标就是不可逆。
常见错误现象：select MD5('123'), SHA2('123', 256) 能算出值，但没有任何 MySQL 函数能从这个结果还原出 '123'。
- 使用场景：密码存储（配合盐值）、数据校验、去重索引（如用
SHA2(email, 256)建唯一索引避免明文泄露） - 参数差异：
SHA2(str, hash_length)的hash_length必须是 224/256/384/512，不是位数也不是任意数字；MD5()无参数，固定输出 32 位十六进制字符串 - 性能影响：计算快，但不抗碰撞（
MD5已不推荐用于安全场景），SHA2(256)更稳妥
AES_ENCRYPT() 和 AES_DECRYPT() 才是真加密/解密对
只有这对函数支持可逆加解密，但必须严格匹配密钥、模式、填充方式，否则返回 NULL 且不报错——这是最常踩的坑。
常见错误现象：SELECT AES_DECRYPT(AES_ENCRYPT('hello', 'key'), 'key') 看似能用，但实际生产中几乎必失败，因为默认使用 ECB 模式且不处理密钥长度和填充。
- 密钥必须是 16/24/32 字节（对应 AES-128/AES-192/AES-256），
'key'只有 3 字节，MySQL 会静默截断或补零，导致加解密不一致 - 强烈建议显式指定模式和 IV：
AES_ENCRYPT(str, key, 'AES-256-CBC', iv)，其中iv必须是 16 字节二进制值（如UNHEX('010203...')） - 加密结果是二进制，存入字段前务必用
HEX()转成字符串；解密前用UNHEX()还原，否则AES_DECRYPT()返回NULL - 兼容性注意：MySQL 5.7+ 才支持带
iv参数的完整签名；低版本只能用AES_ENCRYPT(str, key)（ECB 模式，不安全）
实际存取敏感字段时，别忘了字符集和字段类型
加密后的数据是二进制流，如果字段定义为 VARCHAR + utf8mb4，插入 HEX(AES_ENCRYPT(...)) 没问题，但直接存 AES_ENCRYPT() 结果就可能乱码或截断。
- 推荐方案：加密后转
HEX()存进VARCHAR(64)（AES-256-CBC 加密后 base64 编码约 44 字符，HEX 是 64 字符） - 错误操作：
INSERT INTO t(data) VALUES (AES_ENCRYPT('x', @key))插入到VARCHAR字段，MySQL 会尝试按连接字符集转换二进制，大概率损坏 - 解密时顺序不能错：先
UNHEX()，再AES_DECRYPT()，最后用CONVERT(... using utf8mb4)确保字符串可读（如果原始是文本）
密钥管理不在 MySQL 里做
把密钥写死在 SQL 里（比如 SET @key = 'mysecret123'）或硬编码在应用配置中，等于没加密。
- MySQL 本身没有密钥轮换、访问审计、HSM 集成能力
- 生产环境应由应用层统一管理密钥：用 KMS（如 AWS KMS、HashiCorp Vault）获取动态密钥，或通过环境变量注入，绝不在数据库里存密钥字段
- 如果非要在 DB 层控制权限，至少用 MySQL 8.0+ 的角色机制限制只有特定用户能执行
AES_DECRYPT()，但这只是辅助手段
加密逻辑看似一行函数调用，真正难的是密钥生命周期、IV 安全分发、二进制数据落地格式、以及和应用层加解密行为的一致性——这些地方出错，数据就永久不可读。