MySQL用户认证密码采用不可逆哈希（如8.0的caching_sha2_password），业务数据敏感字段才用AES等对称加密；直接SQL哈希不安全，应于应用层用Argon2/Bcrypt等慢哈希并妥善存盐；还需TLS传输、权限最小化、审计日志等协同防护。

MySQL 的密码加密方式不是单一的，而是随版本演进、用途不同而变化。核心原则是：用户认证密码（即 mysql.user 表中存储的密码）采用不可逆哈希，而非可解密的加密；而业务数据中的敏感字段（如用户手机号、身份证号）才适合用 AES 等对称加密函数处理。

用户认证密码：哈希为主，带插件机制

MySQL 8.0 默认使用 caching_sha2_password 插件，底层基于 SHA-256 哈希，并加入随机盐值和多次迭代（PBKDF2 风格），抗暴力与彩虹表能力显著增强。该插件要求客户端支持 TLS 或高版本驱动（如 MySQL Connector/J 8.0+）。

MySQL 5.7 及更早默认为 mysql_native_password，使用 SHA-1 哈希加盐，但安全性较弱，已不推荐用于生产环境。

历史遗留方式还包括：
– OLD_PASSWORD()（MYSQL323，仅 MySQL 4.1 以前）
– PASSWORD()（SHA-1，MySQL 4.1–5.7，默认但已弃用）
这些函数在 MySQL 8.0 中已被移除，执行会报错。

为什么不用 AES_ENCRYPT 存用户密码？

因为密码验证必须是单向过程：系统只比对哈希值，绝不还原原始密码。若用 AES_ENCRYPT 加密密码：

• 一旦密钥泄露，所有密码可被批量解密
• 无法安全实现“忘记密码”重置（只能重置，不能找回）
• 违背最小权限与纵深防御原则

所以 AES_ENCRYPT/AES_DECRYPT 仅适用于业务字段（如订单备注、用户地址），且密钥必须由应用层安全保管，绝不能硬编码或存入数据库。

真正安全的密码存储实践

即使 MySQL 提供了 SHA2() 函数，也不建议直接在 SQL 层做哈希——容易遗漏盐值管理或迭代轮数控制。推荐做法是：

• 在应用层生成高强度随机盐（如 16 字节以上）
• 使用标准慢哈希算法：PHP 用 password_hash($pwd, PASSWORD_ARGON2ID)，Java 用 BCryptPasswordEncoder，Python 用 passlib.hash.argon2
• 将哈希结果（含算法标识、盐、轮数等）整体存入 password_hash 字段（VARCHAR(255)）
• 验证时调用对应 verify 方法，不手动拼接盐再哈希

这种方案比纯 MySQL 内置函数更可控、更符合 OWASP 密码存储规范。

传输与存储层的协同防护

光靠密码哈希不够，还需叠加其他机制：

• 连接加密：强制客户端使用 TLS 1.2+ 连接，防止密码哈希在传输中被中间人截获（即使哈希本身不可逆，也需防重放与嗅探）
• 账号权限最小化：避免用 root 执行应用查询；为每个服务创建专用账号并限制 IP、库、表、操作类型
• 审计日志开启：启用 general_log 或 error_log + 审计插件，监控异常登录与密码修改行为
• 定期轮换强密码：对高权限账号（如 backup、monitor 用户）设置 90 天有效期，并禁用空密码、简单密码

MySQL 企业版还支持透明数据加密（TDE），可加密 ibd 表空间文件，但这是操作系统/存储层补充手段，不能替代密码哈希本身。