触发器中AES_ENCRYPT失败主因是密钥或明文为NULL、长度非法、字段字符集不匹配；加密列须定义为VARBINARY(255)，密钥硬编码32字节，解密需CAST转CHAR。
触发器里直接调用 AES_ENCRYPT 会失败？先确认密钥和字符集
MySQL 触发器中调用 AES_ENCRYPT 失败，最常见的原因是传入的密钥或明文是 NULL、长度不合法，或字段字符集不支持二进制存储。该函数返回 VARBINARY，若目标字段是 VARCHAR 或未声明足够长度，插入时会静默截断甚至报错 Truncated incorrect DOUBLE value（尤其在严格模式下）。
实操建议：
- 加密字段必须定义为
VARBINARY(255)或更长（AES 加密后长度 ≈ 原始长度 + 16 字节对齐，255 足够覆盖多数文本） - 密钥建议用固定字符串（如
'my-secret-key-32-bytes-long-xxxxxx'），避免从 NULL 列或空字符串动态取值 - 确保表使用
utf8mb4字符集，但加密列本身不参与字符集转换——它存的是二进制，不是文本 - 测试前先手动执行：
SELECT AES_ENCRYPT('test', 'key');看是否返回非 NULL 的VARBINARY值
BEFORE INSERT 触发器中加密字段要绕过 NEW.column = ... 的隐式类型转换
如果目标字段定义为 VARCHAR，直接写 SET NEW.phone = AES_ENCRYPT(NEW.phone, 'key'); 会导致 MySQL 尝试把二进制结果转成字符串，产生乱码或警告。这不是语法错误，但后续 AES_DECRYPT 会失败。
实操建议：
- 加密列必须声明为
VARBINARY，例如：phone_enc VARBINARY(255) - 触发器中只操作加密列，原明文列可保留（用于展示/索引）或设为
INVISIBLE（MySQL 8.0+） - 正确写法：
SET NEW.phone_enc = AES_ENCRYPT(NEW.phone, 'my-32-byte-secret-key-xxxxxxxxxx'); - 不要在触发器里对同一字段反复赋值（比如先赋明文再赋密文），MySQL 不允许对
NEW同一字段多次SET
为什么 AES_DECRYPT 返回 NULL？检查密钥、填充和字段长度
解密返回 NULL 是最常被误判为“加密失败”的现象，实际几乎全是解密侧问题：密钥不一致、密文被截断、或用了错误的字符集强制转换。
实操建议：
- 密钥必须**字节级完全一致**：空格、大小写、长度（推荐 32 字节 AES-256）都不能差一个字节
- 确认加密列没被意外转成
VARCHAR：用SHOW CREATE TABLE t;查看字段类型，不是VARBINARY就重改 - 解密时加
CAST(... AS CHAR)显式转回字符串：CAST(AES_DECRYPT(phone_enc, 'key') AS CHAR) - 如果原始数据含中文且解密后乱码，大概率是插入前被自动转了字符集——检查客户端连接编码（
SET NAMES utf8mb4）和列定义
性能与安全边界：别在触发器里做密钥管理或条件加密
触发器内硬编码密钥是常见做法，但无法动态轮换；若尝试从配置表查密钥，会引发递归锁或权限问题（触发器默认以定义者权限运行，可能无权查其他表）。另外，对所有行无差别加密会拖慢大批量 INSERT。
实操建议：
- 密钥必须写死在触发器 SQL 里，不要用变量或子查询获取（MySQL 不允许）
- 避免在触发器里加
IF NEW.sensitive = 1 THEN ...这类逻辑——增加分支判断开销，且易漏掉边缘 case - 批量导入时，考虑关掉触发器（
SET @disable_trigger = 1;+ 在触发器开头判断），或改用应用层加密 - 真正需要密钥轮换时，应重建触发器 + 全量重加密数据，没有“热切换”方案
触发器加密本质是“透明预处理”，它不提供密钥隔离、访问审计或加密算法协商能力。一旦业务需要这些，就得切到应用层或专用加密代理——别指望靠改几行 SET NEW.x = AES_ENCRYPT(...) 解决。
