MySQL中AES_ENCRYPT/AES_DECRYPT密钥必须为16/24/32字节，推荐UNHEX()传固定十六进制密钥；存储用VARBINARY/BLOB；默认ECB模式不安全，敏感数据应改用应用层加密。
MySQL中AES_ENCRYPT和AES_DECRYPT的密钥长度必须严格匹配
AES_ENCRYPT(AES_ENCRYPT) 要求密钥长度为128、192或256位（即16、24、32字节），否则会静默截断或填充，导致AES_DECRYPT无法还原。常见错误是传入短字符串如'mykey'——它只有7字节，MySQL会用零字节补足到16字节，但下次用同样字符串解密时若环境字符集不同（比如连接层用了utf8mb4），实际送入的字节数可能变成14（含BOM或变长编码），解密就返回NULL。
实操建议：
- 始终用
UNHEX()配合固定长度十六进制字符串生成密钥，例如UNHEX('A1B2C3D4E5F678901234567890ABCDEF')（32字符 → 16字节） - 避免直接用明文字符串作密钥；若必须，先用
SHA2(str, 256)哈希再UNHEX(SUBSTR(..., 1, 32))取前32字符转为16字节 - 在
SELECT中测试密钥一致性：SELECT LENGTH(AES_ENCRYPT('test', UNHEX('...')))应返回非NULL且长度稳定（通常32字节起）
加解密结果是BLOB类型，不能直接SELECT显示为可读文本
AES_ENCRYPT返回BLOB，直接SELECT AES_ENCRYPT('hello', @key)在命令行客户端可能显示乱码或空，不是失败，而是二进制数据被终端误解析。更麻烦的是，如果字段定义为VARCHAR却存了加密结果，MySQL会按连接字符集尝试转换，造成数据损坏。
实操建议：
- 存储加密值务必使用
VARBINARY(255)或BLOB类型，禁用VARCHAR - 调试时用
HEX(AES_ENCRYPT(...))转为十六进制字符串查看，解密前用UNHEX()还原，例如：SELECT AES_DECRYPT(UNHEX('C2A...'), @key) - 应用层读取后，需将
VARBINARY原始字节按原逻辑解码（比如UTF-8），不能依赖MySQL自动字符集转换
默认使用AES-128-ECB模式，不带IV，安全性弱
MySQL 5.7+ 的AES_ENCRYPT默认用ECB模式（电子密码本），相同明文块永远加密成相同密文块，容易被频率分析；且不支持指定IV（初始化向量），无法升级到CBC等更安全模式。这意味着：它只适合低敏感场景（如混淆日志ID），**绝不能用于密码、身份证、银行卡等真实敏感字段**。
实操建议：
- 确认业务风险等级——若需合规（如等保、GDPR），应改用应用层加密（如PHP的
openssl_encrypt配CBC+随机IV） - 若坚持用MySQL内置函数，至少加上盐值：把明文拼上唯一字段（如
CONCAT(user_id, ':', plain_text)）再加密，缓解重复明文问题 - 注意MySQL 8.0.30+ 开始支持
AES_ENCRYPT(str, key, init_vector)三参数形式（需启用block_encryption_mode='aes-256-cbc'），但IV必须16字节且每次不同，管理成本陡增
跨会话/跨客户端解密失败，大概率是字符集或连接变量不一致
同一个AES_DECRYPT语句，在phpMyAdmin里成功、在MySQL Shell里返回NULL，往往是因为：① 客户端声明的character_set_client不同，影响字符串参数编码；② collation_connection导致隐式转换；③ 加密时用的密钥变量（如@key）在另一会话未定义。
实操建议：
- 统一设置连接字符集：
SET NAMES utf8mb4;并确认character_set_client、collation_connection、character_set_results三者一致 - 密钥不要依赖用户变量
@key，改用确定字面量或存储过程参数，避免会话隔离问题 - 用
SELECT @@version, @@block_encryption_mode;核对服务端配置，老版本（
