MySQL 用户密码默认用 SHA256
还是 caching_sha2_password
？
MySQL 8.0+ 默认认证插件是
caching_sha2_password，它底层使用 SHA256 哈希，但不是直接存
SHA256(password)——而是用加盐的 PBKDF2 衍生密钥（salt + 5000 轮 SHA256），再经 AES 加密存储。所以不能简单用
SHA256()函数模拟其哈希值。
查看当前用户插件：
SELECT user, host, plugin FROM mysql.user WHERE user = 'your_user';若
plugin是
caching_sha2_password，密码字段
authentication_string是加密后的二进制 blob（不可逆、不可读） 若为
mysql_native_password，
authentication_string是纯 SHA1 哈希（旧协议，不推荐） 不建议手动更新
authentication_string字段——必须用
ALTER USER或
SET PASSWORD，否则会破坏认证流程
用 ALTER USER
安全改密，别碰 mysql.user
表
直接 UPDATE
mysql.user表不仅无效（MySQL 8.0+ 会忽略），还可能锁表或触发权限异常。正确方式始终走 SQL 命令：
ALTER USER 'admin'@'localhost' IDENTIFIED BY 'NewP@ssw0rd2024!';该语句自动调用对应插件的密码派生逻辑（如
caching_sha2_password会生成新 salt 并重算） 如果要强制降级兼容老客户端，可指定插件：
ALTER USER 'app_user'@'%' IDENTIFIED WITH mysql_native_password BY 'legacy_pwd';执行后需
FLUSH PRIVILEGES;（仅当手动改表后才真需要；正常用
ALTER USER不必）
应用层连接时密码明文传输？得靠 TLS 或 sha256_password
插件
即使服务端用了强哈希，如果客户端用明文传密码（比如 JDBC URL 没开 SSL），中间人仍能截获。两种缓解路径：
启用 TLS：在连接字符串中加?useSSL=true&requireSSL=true（MySQL Connector/J），服务端需配置
ssl-ca/
ssl-cert等 用
sha256_password插件（注意不是
caching_sha2_password）：它要求客户端用 RSA 公钥加密密码后再传，服务端用私钥解密——前提是服务端已生成密钥对并配置
sha256_password_private_key_path
caching_sha2_password默认走安全通道协商；若连接未加密且无 RSA 密钥，会退回到明文传输（日志里报
Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection.）
自定义密码策略：靠 validate_password
插件，不是加密逻辑本身
MySQL 不负责“密码强度校验”的加密实现，而是通过插件控制创建/修改密码时的合规性。启用后，
ALTER USER会校验密码是否满足规则：
INSTALL PLUGIN validate_password SONAME 'validate_password.so';
常用参数（写入
my.cnf或运行时设）：
validate_password.length：最小长度（默认 8）
validate_password.mixed_case_count：至少几个大小写字母（默认 1）
validate_password.number_count：至少几个数字（默认 1）
validate_password.special_char_count：至少几个特殊字符（默认 1）
validate_password.policy：0=LOW（只校验长度）、1=MEDIUM（加字数/数字/特殊符）、2=STRONG（再加字典检查）
这些策略不影响已有密码的哈希方式，只拦住弱密码被设进去。一旦设了强策略，连
root改密也得遵守——这点常被忽略，导致运维卡住。
