MySQL 8.0+ 默认认证插件是 caching_sha2_password，它基于加盐 PBKDF2（5000 轮 SHA256）派生密钥并 AES 加密存储，非直接 SHA256 哈希；须用 ALTER USER 修改密码，禁用手动更新 mysql.user 表。
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），中间人仍能截获。两种缓解路径：
word报告自动生成神器
下载
Word报告自动生成神器。自动生成专业Word文档报告，支持模板填充、目录生成、表格/图表插入、页眉页脚、多级标题、样式主题、批量邮件合并。当用户需要生成Word报告、创建合同文档、批量生成通知/证书、填充Word模板、制作商业计划书时触发。
- 启用 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 改密也得遵守——这点常被忽略，导致运维卡住。
