不能在UPDATE语句里直接调用解密函数再加密写回，因会导致密文错乱、事务中断或权限报错；AES_DECRYPT(AES_ENCRYPT())链式写法不可靠，主因是隐式字符集转换截断数据、密钥字符集解析不一致及单行失败致整条UPDATE中断。
不能在UPDATE语句里直接调用解密函数再加密写回——这会导致密文错乱、事务中断或权限报错。
为什么AES_DECRYPT(AES_ENCRYPT())链式写法不可靠
表面看，MySQL 支持类似 AES_ENCRYPT(AES_DECRYPT(encrypted_col, @key), @key) 的写法，但实际有三个致命问题：
-
AES_DECRYPT()返回VARBINARY，若原始明文含随机 IV 或填充字节，隐式转字符集（如utf8mb4）会截断或乱码，再加密就不是原值 - 密钥
@key若未显式转为BINARY（如CONVERT(@key USING BINARY)），MySQL 会按连接字符集解析，导致加解密不匹配 - 某行解密失败（密文损坏、密钥错误）时，整条
UPDATE直接报错中断，无法定位哪一行出问题，也无法跳过继续处理
真正安全的更新流程：应用层解密→校验→重加密→原子写入
数据库只负责存新密文，不参与明文处理。所有逻辑必须收口到应用层：
- 先用稳定密钥和标准模式（如
AES-256-GCM）解密目标行，捕获padding error、tag mismatch等异常，记录失败 ID 和错误类型 - 对解密后的明文做业务逻辑处理（如修改邮箱域名、脱敏手机号后 4 位），并重新校验格式合法性
- 用同一套密钥+新 IV（CBC/CBC-GCM 模式下必须每次生成新 IV）重新加密，IV 与密文一起存入对应字段（如
iv列 +encrypted_col列） - 写入时用
WHERE encrypted_col = ?做乐观锁校验，防止并发覆盖（即两个事务各自读旧密文→改明文→加密写回，后写者丢弃前写者变更）
达梦/SQL Server/GaussDB 等需额外注意的点
不同数据库对加密字段的类型、密钥管理和执行阶段限制差异大：
- 达梦（DM）使用分级密钥（
SVR_KEY/DB_KEY），密钥轮换必须调用SP_UPDATE_DBKEY()，且存量数据需手动重加密，不能依赖 SQL 自动刷新 - SQL Server 的
Always Encrypted要求客户端 ODBC 驱动启用ColumnEncryption=Enabled，服务端从不接触明文；UPDATE 时参数自动加密，但无法在 WHERE 中用明文条件查加密列（得用确定性加密 + 匹配参数） - GaussDB(DWS) 不兼容 MySQL/Oracle 的密文格式，迁移时必须先在源库解密导出明文，再在 DWS 侧用
aes256或sm4重加密，不能直传密文
最易被忽略的是密钥生命周期管理——硬编码密钥、复用 IV、跨版本密钥长度不一致（如 MySQL 5.6 vs 5.7+ 对 24 字节密钥的处理差异），都会让“更新”变成“静默破坏”。上线前务必用真实密文样本，在新旧环境跑通 HEX(AES_ENCRYPT()) 对比测试。
