aes_encrypt不适合直接用于生产环境，除非解决密钥管理、iv生成、字符集转换、字段类型和模式选择五大前提；其默认ecb模式无iv、密钥长度无校验、易致明文模式泄露且加解密不一致。
AES_ENCRYPT 不适合直接用于生产环境的敏感字段加密，除非你已解决密钥管理、IV 生成、字符集转换、字段类型和模式选择这五个硬性前提。
为什么 AES_ENCRYPT(str, key) 在生产里大概率失效
这是最常被忽略的起点：MySQL 默认用 ECB 模式（AES-128-ECB），不带 IV，且对密钥长度无校验。比如 AES_ENCRYPT('13812345678', 'abc') 中密钥只有 3 字节，MySQL 会静默补零到 16 字节，但不同连接、不同版本行为可能不一致；更糟的是，ECB 会让所有以“138”开头的手机号加密后前两字节完全相同，攻击者靠频次就能反推明文。
常见错误现象包括：
-
AES_DECRYPT()返回NULL，却不报错——实际是密钥类型/长度/IV/模式四者中任一不匹配 - 字段设为
VARCHAR(255)存AES_ENCRYPT()结果，查出来是乱码或截断 - 应用层传入含空格或换行的密钥，MySQL 自动截断导致加解密不一致
- 升级 MySQL 8.0.31+ 后，执行报错
ERROR 3719，因默认禁用非确定性加密函数
必须显式指定 CBC 模式 + IV + 二进制密钥
ECB 是安全红线，必须绕开。MySQL 5.7.4+ 支持三参数签名：AES_ENCRYPT(str, key_str, iv)，但 iv 必须是 16 字节二进制值，不能是字符串。
实操建议：
- 密钥别手输，用
UNHEX(SHA2('your_service_salt_2026', 256))生成固定 32 字节密钥（对应 AES-256） - IV 每次加密都必须新生成，推荐用
FROM_BASE64(RAND_BYTES(16))或应用层生成后传入 - 加密时调用：
AES_ENCRYPT(CONVERT('13812345678' USING binary), @key, @iv) - 解密时顺序不能错：
CONVERT(AES_DECRYPT(UNHEX(hex_ciphertext), @key, @iv) USING utf8mb4) - MySQL 8.0.17+ 可选
AES_ENCRYPT(..., 'AES-256-GCM', @iv, @aad)，但需确认客户端驱动支持
字段类型、存储格式与字符集必须严格对齐
加密结果是二进制流，不是文本。存错类型等于自毁解密能力。
- 字段类型必须是
VARBINARY(255)（不是VARCHAR，也不是BLOB——后者不支持索引） - 若业务要求存十六进制字符串（便于日志排查或跨系统传输），则加密后套
HEX()，字段用VARCHAR(64)（AES-256-CBC 加密 20 字节原文 ≈ 48 字节 HEX） - 原始数据是
utf8mb4？加密前务必CONVERT(str USING binary)，否则中文可能因隐式转换损坏 - 解密后若要转回可读字符串，必须
CONVERT(... USING utf8mb4)，且确保原始加密前也是同字符集 - 别在 SQL 里写死密钥：
AES_ENCRYPT(data, 'mykey123')—— 密钥应由应用通过环境变量注入，SQL 只接收参数化输入
真正难的从来不是函数怎么写
写对一条 AES_ENCRYPT() 很容易，但生产环境要跑稳三年不出事，得回答清楚：
- 密钥轮换时，旧数据怎么迁移？MySQL 不支持就地重加密，只能靠应用层双写+灰度切换
- 谁有权限读取密钥？DBA 能否绕过应用直连解密？是否需要 DBA 也无权接触明文？
- 备份文件里的加密字段，恢复后能否解密？备份时密钥是否同步导出？
- 审计日志里会不会留下
AES_ENCRYPT(..., 'xxx')这样的明文密钥痕迹？
这些都不在 AES_ENCRYPT 的文档里，而在你的部署清单、权限矩阵和密钥生命周期 SOP 中。
