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 表空间文件，但这是 操作系统/ 存储层补充手段，不能替代密码哈希本身。
