MySQL 8.0 升级后应淘汰 mysql_native_password，因其使用无 salt 的 SHA1 易被爆破且已弃用；须批量改用 caching_sha2_password，并清理配置中残留的旧 default_authentication_plugin 设置。
mysql_native_password 本身不是攻击面，而是旧认证协议；真正的问题是：升级到 MySQL 8.0 后，默认启用 caching_sha2_password，但老客户端连不上——这时有人误以为“必须保留 mysql_native_password 才安全”，结果反而暴露了更弱的认证路径。
别绕弯子：MySQL 5.7 升级到 8.0 的核心安全动作，不是“加固 mysql_native_password”，而是主动淘汰它，并确保所有连接走现代协议。
为什么不能继续用 mysql_native_password？
mysql_native_password 使用 SHA1 哈希 + challenge-response，不带 salt，可被离线字典爆破；MySQL 官方自 8.0 起将其标记为“deprecated”，并在后续版本中计划移除。它不是“不够强”，而是“设计上已过时”。
- 不支持密码轮换后的密钥派生（如 PBKDF2）
- 无法抵御重放或中间人（即使走 TLS，认证阶段仍脆弱）
- PHP
mysqlnd5.0.12 以下、PythonMySQLdb、旧 JDBC 驱动报错Authentication plugin 'caching_sha2_password' cannot be loaded，本质是驱动太老，不是协议该留着
升级后立刻执行的三步认证修复
升级完成、MySQL 8.0 启动成功后，第一件事不是改应用，而是收紧数据库侧配置：
- 登录 MySQL：
mysql -u root -p（用原 5.7 密码，8.0 会自动兼容旧插件登录） - 批量切换所有业务用户（含
root）：ALTER USER 'user_name'@'host' IDENTIFIED WITH caching_sha2_password BY 'new_strong_pwd'; - 在
/etc/my.cnf或/etc/my.cnf.d/mysql-server.cnf的[mysqld]段加：default_authentication_plugin=caching_sha2_password（防止新建用户又掉回mysql_native_password）
注意：FLUSH PRIVILEGES; 不需要——ALTER USER 已即时生效。
客户端不升级？那就只给最小权限的兼容账号
真有短期无法升级的客户端（比如嵌入式设备固件、老旧监控脚本），不要全局降级，而是单独建一个受限账号：
- 新建账号限定 IP 和用途：
CREATE USER 'legacy_app'@'192.168.10.5' IDENTIFIED WITH mysql_native_password BY 'pwd_2026!'; - 只赋必要库表 SELECT 权限：
GRANT SELECT ON app_db.orders TO 'legacy_app'@'192.168.10.5'; - 禁用远程 root 登录：
DROP USER 'root'@'%';，只留'root'@'localhost'且强制用caching_sha2_password
这种账号必须设短过期时间（PASSWORD EXPIRE INTERVAL 90 DAY），并记录在运维台账里——它不是方案，是临时补丁。
最容易被忽略的坑：my.cnf 里的 default_authentication_plugin 没删干净
很多团队在 5.7 时代为兼容老系统手动加过 default_authentication_plugin=mysql_native_password。升级后若没检查并删除这行，哪怕执行了 ALTER USER，新创建的账号（比如运维脚本自动建的）仍会继承旧插件，等于埋了个静默后门。
执行：grep -r "default_authentication_plugin" /etc/my.cnf* 2>/dev/null，确认输出只有你刚加的那行 caching_sha2_password，其余全部删掉。
