如何使用MySQL提供的加密函数保护敏感字段数据？-mysql教程-PHP中文网

aes_encrypt/aes_decrypt是可逆加密的唯一可行方案，md5/sha2因不可逆无法满足身份证、手机号等需还原明文的业务需求；密钥严禁硬编码，字段必须用varbinary/blob存储二进制密文，解密后需cast为char才能正常显示。

如何使用mysql提供的加密函数保护敏感字段数据？

直接用 AES_ENCRYPT 和 AES_DECRYPT 加密字段最可行，但密钥硬编码、字段类型不匹配、解密结果乱码这三类问题占实际踩坑的 80% 以上。

为什么不能用 MD5 或 SHA2 加密身份证/手机号

MD5 和 SHA2 是哈希函数，不可逆。它们只适合密码校验这类“只需比对、无需还原”的场景。如果把身份证号用 SHA2('11010119900307281X', 256) 存进去，后续连自己都查不到原始号码——业务系统根本没法做实名核验、短信通知或人工客服调阅。

误用现象：把 ssn、phone 字段用 MD5() 插入，之后 SELECT 时发现返回的全是哈希串，无法展示或导出明文
正确边界：仅对 password_hash 这类字段用 SHA2(?, 256)，且必须加盐（应用层生成随机 salt 并拼接）
替代方案：需要可逆的，就只能选 AES_ENCRYPT；若担心密钥泄露风险高，应移至应用层加密，数据库只存密文

AES_ENCRYPT 写入时字段类型必须是 VARBINARY 或 BLOB

AES_ENCRYPT 返回的是二进制数据，不是字符串。如果目标字段定义为 VARCHAR 或 TEXT，MySQL 会静默截断或转码，导致后续 AES_DECRYPT 失败并返回 NULL。

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

建表示例：CREATE TABLE users (id INT, name VARCHAR(32), phone VARBINARY(255));
错误写法：INSERT INTO users(phone) VALUES(AES_ENCRYPT('13800138000', 'key')); —— 若 phone 是 VARCHAR，插入后查出来就是乱码或空值
验证方法：SELECT LENGTH(phone) FROM users; 正常 AES 密文长度约 16~48 字节（取决于明文长度和填充），远小于 VARCHAR 声称的长度
注意：不要用 TINYBLOB 存长文本，它上限只有 255 字节；优先选 VARBINARY(512) 或 BLOB

AES_DECRYPT 返回二进制，显示前必须 CAST 成字符串

AES_DECRYPT 的返回值类型是 VARBINARY，直接 SELECT 会看到十六进制或乱码。不显式转换，应用层拿到的就是 raw bytes，PHP/Python 可能报 UnicodeDecodeError，Java 可能抛 MalformedInputException。

正确写法：SELECT name, CAST(AES_DECRYPT(phone, 'key') AS CHAR) AS phone FROM users;
错误写法：SELECT name, AES_DECRYPT(phone, 'key') FROM users; —— 结果列类型仍是 binary，多数客户端不自动渲染为可读文本
兼容性提醒：MySQL 8.0+ 支持 CAST(... AS CHAR)，但旧版本需用 CONVERT(... USING utf8mb4)
性能影响：每次查询都做 CAST 无显著开销；但避免在 WHERE 条件里对解密结果做 LIKE 模糊匹配——会全表扫描且无法走索引

密钥绝不能出现在 SQL 文本里

把密钥写死在 INSERT 或 SELECT 语句中（如 AES_ENCRYPT('xxx', 'my_key_2026')），等于把保险柜钥匙焊在柜门上。只要有人能执行 SHOW CREATE VIEW / SELECT FROM information_schema.PROCESSLIST，就能看到完整密钥。

安全做法：密钥由应用代码传入，通过参数化查询传递，例如 Python 的 cursor.execute("INSERT ... VALUES (%s)", (aes_encrypt(data, key),))
配置建议：密钥存环境变量（MYSQL_AES_KEY）或 KMS，禁止写进 my.cnf、SQL 文件或 Git 仓库
轮换难点：AES 是对称加密，换密钥后旧数据无法用新密钥解密。如需轮换，得在应用层实现双密钥过渡逻辑，或批量重加密历史数据
特别注意：MySQL 9.6.0 虽支持 container_aware 启动，但不改变密钥管理责任——它只帮你加载环境变量，不帮你判断密钥是否该轮换

真正麻烦的不是函数怎么调用，而是密钥生命周期管理和加解密路径一致性。比如应用 A 用 UTF-8 编码加密，应用 B 用 latin1 解密，哪怕密钥完全一致，结果也是 NULL；再比如前端传参没 trim 空格，加密后多一个字节，解密就失败。这些细节不在文档里，但在日志里高频出现。