在 my.cnf 中设置 default_authentication_plugin 为什么有时不生效
在 MySQL 8.0 的配置中，有一个问题经常让人困惑：明明在 my.cnf 文件里写上了 default_authentication_plugin = mysql_native_password，可为什么就是不起作用呢？
其实，这个看似简单的配置背后，藏着几个典型的“坑”。直接往 [mysqld] 段里加一行，思路没错，但导致它失效的常见原因主要有三个：配置段放错了位置、服务没有完整重启，或者你用的根本就是不允许修改此参数的云数据库。更关键的是，必须明确一点：这个配置只对之后新创建的用户生效。那些已经存在的用户，其认证方式纹丝不动。所以，即便配置成功了，老应用连接不上的问题，依然会原封不动地摆在那里。
my.cnf 配置必须放在 [mysqld] 段下
第一个容易出错的地方就是配置段。很多朋友会下意识地把配置加到 [client] 或者 [mysql] 段里，但这仅仅会影响客户端工具的行为，对于服务器端选择默认认证插件这件事，是完全没有作用的。正确的姿势，必须像下面这样：
[mysqld] default_authentication_plugin = mysql_native_password
配置完成后，怎么验证它是否真的生效了呢？连接上 MySQL，执行一句查询：SELECT @@default_authentication_plugin;。如果返回值是 mysql_native_password，那就恭喜你，配置对了。如果返回的还是 caching_sha2_password，那就说明配置要么没被加载，要么被其他设置给覆盖了。
改完必须重启 mysqld，不是 reload
第二个关键步骤是重启服务，而且必须是完整重启。执行 sudo systemctl reload mysqld 这种重载命令，并不会让 MySQL 重新读取 default_authentication_plugin 这个参数。正确的操作流程是：
sudo systemctl stop mysqldsudo systemctl start mysqld
当然，环境不同，命令也有差异。比如在 macOS 上用 Homebrew 安装的，就需要用 brew services restart mysql；如果是 Docker 容器，通常需要重建容器，或者进入容器执行 docker exec -it mysql-container bash -c “kill -SIGTERM 1” 来让主进程重启。重启之后，别忘了再次验证 @@default_authentication_plugin 的值。
云数据库（RDS/CDB）这条路基本走不通
如果你使用的是阿里云 RDS、腾讯云 CDB 或 AWS RDS 这类托管数据库服务，那么前面讨论的方法很可能根本行不通。为什么？因为云服务商出于管理和安全的考虑，通常会对 my.cnf 的权限进行严格控制，default_authentication_plugin 恰恰就属于那个被禁止修改的参数列表里的一员。在控制台或者 API 中，你也基本找不到这个选项。
那么，在云数据库上遇到兼容性问题怎么办？答案是：绕道而行。唯一的可行路径是“逐个击破”——针对每一个出现连接问题的应用账号，单独修改其认证方式。具体操作如下：
ALTER USER ‘app_user’@’%’ IDENTIFIED WITH mysql_native_password BY ‘xxx’; FLUSH PRIVILEGES;
这里有个细节需要特别注意：语句中的 ‘app_user’@’%’，其用户名和主机部分必须与 SELECT User, Host FROM mysql.user; 查询出来的结果完全一致。哪怕主机部分一个是 % 一个是 localhost，都会被 MySQL 视为两个不同的用户，从而导致 “Operation ALTER USER failed for …” 这样的报错。所以，修改前务必先核对清楚。
