MySQL 5.7 中 default_authentication_plugin 配置无效：该变量未在源码中注册，写入 my.cnf [mysqld] 段会被忽略，SHOW VARIABLES 查不到，所有用户默认且仅支持 mysql_native_password。
MySQL 5.7 中 default_authentication_plugin 配置无效
直接告诉你结论：default_authentication_plugin 在 MySQL 5.7 中根本不起作用，写进 my.cnf 的 [mysqld] 段也会被忽略。这不是配置写错，而是源码里压根没注册这个变量。
你执行 SHOW VARIABLES LIKE 'default_authentication_plugin%'; 查不到结果，或返回空；SELECT @@default_authentication_plugin; 会报错或无返回——因为它不存在。
- 5.7 唯一支持的认证插件是
mysql_native_password，所有用户（包括 root）默认且只能用它 - 如果你看到某个用户的
plugin字段不是mysql_native_password，说明有人手动执行过ALTER USER ... IDENTIFIED WITH ...，而 5.7 实际不支持该插件的 server-side 验证逻辑，这种用户大概率无法登录 - 真正要检查的是：运行
SELECT User, Host, plugin FROM mysql.user WHERE User = 'your_user';，结果必须是mysql_native_password
MySQL 8.0 全局修改 default_authentication_plugin 的前提条件
这个配置只在 MySQL 8.0+ 生效，但生效有硬性前提：必须写在 [mysqld] 段，且必须完整重启服务。
常见失效原因不是配置写错，而是：
- 配置误放在
[client]或[mysql]段——这只会改客户端行为，不影响服务端默认插件 - 执行了
systemctl reload mysqld而非systemctl restart mysqld——reload不重读default_authentication_plugin - 用的是云数据库（如阿里云 RDS、腾讯云 CDB）——该参数被锁定，控制台和 API 均不可修改
验证是否生效，连接后执行：SELECT @@default_authentication_plugin;，返回值应为 mysql_native_password（如果你设的是这个值）。
MySQL 8.0 中修复老客户端连不上，优先改单个用户
比全局改配置更稳、更快、影响更小的操作是直接切换出问题的用户插件。尤其当你不能重启、或用的是云数据库时，这是唯一可行路径。
- 执行语句必须带
IDENTIFIED WITH，仅SET PASSWORD不会改插件，密码哈希格式还是旧的 - 主机名要一字不差匹配，比如用户是
'app'@'10.0.0.%'，就不能写成'app'@'%'，否则报错 “Operation ALTER USER failed for …” - 执行完必须跟
FLUSH PRIVILEGES;，部分 8.0 版本（尤其是某些 RDS）不刷新就不生效 - 如果用户 host 是
localhost，本地连接可能因 socket 解析失败，可临时用127.0.0.1测试确认是否纯插件问题
示例：ALTER USER 'webapp'@'192.168.1.100' IDENTIFIED WITH mysql_native_password BY 'xxx'; FLUSH PRIVILEGES;
容易被忽略的关键点
很多人卡在“配了却没用”，其实是因为混淆了两个完全独立的概念：
-
default_authentication_plugin只决定「新创建用户」的默认插件，对已有用户零影响 - 已有用户插件一旦设定就固化，不会随全局配置变更而自动更新
- MySQL 8.0 升级自 5.7 后，老用户仍保持
mysql_native_password，一般不会出问题；反而是升级后新建的用户（比如运维脚本自动创建的）用了caching_sha2_password，才导致老客户端连不上
所以排查顺序应该是：先查报错用户在 mysql.user 表里的 plugin 值，再决定是改单个用户，还是动全局配置——而不是一上来就改 my.cnf。
