MySQL升级后AES_DECRYPT返回NULL的直接原因是密钥长度、填充方式或字符集不匹配导致解密校验失败；需检查旧库字段字符集、显式定义VARBINARY/BLOB类型、统一AES-128密钥长度、指定加密模式并管理IV、客户端连接设binary字符集。
MySQL升级后AES_DECRYPT返回NULL怎么办
直接原因：密钥长度、填充方式或字符集不匹配，不是“加密失效”，而是解密时校验失败。MySQL 5.7 默认用 utf8mb4，而老版本可能用 latin1 存储密文；升级后若字段没显式指定 COLLATE，AES_DECRYPT 会按新默认规则解析二进制流，导致乱码或截断。
实操建议：
- 先确认旧库中加密字段的原始
CHARACTER SET和COLLATE，用SHOW CREATE TABLE查，重点看VARBINARY或BLOB类型字段是否被误建为VARCHAR - 升级前导出密文时加
HEX()：例如SELECT HEX(aes_encrypted_col) FROM t，避免字符集转换污染二进制数据 - 升级后还原时用
UNHEX()再解密：AES_DECRYPT(UNHEX('...'), @key)，绕过字符集层干扰 - 别依赖
DEFAULT CHARSET，所有加密字段必须显式定义为VARBINARY(255)或BLOB
密钥长度不一致导致AES_ENCRYPT结果不同
MySQL 5.6 默认用 AES-128，但 5.7+ 支持 AES-128/192/256，且 AES_ENCRYPT 对密钥处理逻辑有变：旧版自动补零到16字节，新版严格按密钥字节长度选算法（如24字节密钥触发 AES-192）。同一串密钥在两版本中可能生成不同密文。
实操建议：
- 检查密钥实际字节数：
LENGTH(@key)，不是CHAR_LENGTH()；中文、emoji 等会导致字节长度 > 字符长度 - 统一强制用 AES-128：密钥截取前16字节，或用
LPAD(@key, 16, 0x00)补零，再转成BINARY(16) - 避免用字符串拼接生成密钥，改用
SHA2('seed', 256)截取前16字节，确保确定性 - 测试时对比
HEX(AES_ENCRYPT('test', @key))在新旧环境是否一致，不一致就说明密钥处理逻辑已偏移
从ENCODE/DECODE迁移到AES_ENCRYPT的坑
老系统常用 ENCODE（DES）加解密，但 MySQL 8.0 已弃用该函数，且 DES 强度不足。迁移时不能只换函数名——ENCODE 自动加盐、使用固定 IV，而 AES_ENCRYPT 默认 ECB 模式无 IV，也不加盐，直接替换会导致解密失败。
实操建议：
- 别试图“反向推导”
ENCODE的盐值，它不可逆；应把存量数据用旧逻辑解密后，再用新密钥重新AES_ENCRYPT - 新加密必须指定模式：
AES_ENCRYPT(data, key, iv)，IV 存在单独字段（如iv BINARY(16)），不能硬编码 - ECB 模式禁止用于生产；至少用 CBC，且每次加密生成新 IV，和密文一起存
- 如果原
ENCODE密钥含非 ASCII 字符，注意CONVERT(@key USING latin1)再传入，否则 UTF8 下字节错位
PHP/Python 应用连不上新 MySQL 解密结果
常见现象是应用调用 mysqli_query 或 pymysql 执行 AES_DECRYPT 后字段为空，其实不是 SQL 报错，而是客户端收到的二进制结果被自动转成字符串再 UTF8 解码，破坏了原始字节流。
实操建议：
- MySQL 连接必须设
charset=binary（Python pymysql）或mysql_set_charset('binary', $link)（PHP mysqli），禁用字符集自动转换 - 查询时显式用
HEX(AES_DECRYPT(...))，在应用层用binascii.unhexlify()或hex2bin()还原，比直接取二进制更稳 - 确认应用层密钥变量类型：PHP 中
mb_convert_encoding($key, 'ISO-8859-1', 'UTF-8')防止多字节字符污染 - 别在 SQL 层做解密后再
CONVERT(... USING utf8mb4)，那是把解密后的明文当二进制重解释，必然乱码
