MySQL的身份验证方式决定了客户端用什么算法和流程来证明自己是合法用户。很多刚接触数据库的人以为认证规则写在某个独立配置文件里，其实MySQL把每个用户的认证插件名称直接记录在系统库mysql的user表中。也就是说，身份验证方式的位置既不是单纯的my.cnf，也不是客户端本地，而是服务端系统表里的plugin字段。除此之外，服务器级默认值会影响新创建用户时采用的插件类型，这个默认值可以通过配置文件或启动参数控制。
系统表中身份验证方式的存储位置
MySQL把用户账号和认证信息统一放在mysql.user表。这张表除了包含用户名字段user、允许连接的主机host，还有一个非常关键的列叫做plugin，它记录了该账号当前使用的身份验证插件名称。比如常见的值有mysql_native_password、caching_sha2_password、sha256_password等。当你用客户端连接时，服务端会读取这个plugin列，决定走哪套握手逻辑。因此，想知道某个用户的认证方式在哪里，最直接的位置就是查询这张系统表。
除了plugin列，user表还有authentication_string列，用来存放根据对应插件加密后的密码凭据。不同插件对authentication_string的格式要求不同，例如mysql_native_password存的是两次SHA1哈希结果，而caching_sha2_password存的是SHA256相关摘要。修改plugin时必须配套更新authentication_string，否则会出现密码失效或空密码情况。下面这段查询可以列出所有账号及其认证方式：
SELECT user, host, plugin, authentication_string FROM mysql.user ORDER BY user, host;
从运维角度看，这种把认证方式放在系统表而不是外部文件的设计，好处是改动即时生效且易于用SQL管理。坏处是如果误删了mysql库或user表损坏，所有账号认证都会失灵。所以在迁移或升级MySQL时，一定要用mysqldump导出mysql库，保证user表结构和平常数据一起备份。
通过SQL语句修改已有用户的认证方式
如果发现某个老程序连八点零以上MySQL报authentication plugin caching_sha2_password cannot be loaded，就需要把该用户的plugin改回mysql_native_password。MySQL提供了ALTER USER语句来动态修改，不需要重启服务。语法上通过IDENTIFIED WITH插件名BY密码来同时设定插件和新密码，服务器会自动计算正确的authentication_string。
举例来说，要把本地root账号改成旧版插件，可以执行下面的命令。注意修改后原来的密码会被重置，因此BY后面要写新的明文密码，MySQL会按新插件规则加密存储。执行完毕建议立刻用FLUSH PRIVILEGES刷新权限，虽然ALTER USER多数版本会自动生效，但在一些复制或特殊权限场景下手动刷新更稳妥。
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'NewPass@123'; FLUSH PRIVILEGES;
如果只想看修改结果而不改密码，可以用IDENTIFIED WITH插件名，但部分版本要求同时提供密码。相比之下，统一用BY设定密码最不容易出错。这种SQL层修改的优点是精确到单个用户，不影响其他账号；缺点是要对每个不兼容的账号逐一处理，账号多时会比较繁琐。此时可以写脚本批量生成ALTER USER语句。
服务器默认认证插件配置位置
除了改已有用户，我们还经常关心新用户默认用什么认证方式。这个默认值由系统变量default_authentication_plugin控制，在MySQL八点零前默认是mysql_native_password，八点零后变成caching_sha2_password。想永久调整，需要改服务器配置文件，在Linux上通常是/etc/my.cnf或/etc/mysql/my.cnf，Windows上则是my.ini。在[mysqld]段落加入一行即可。
例如要让新建用户统统使用旧插件，可以这样写配置文件。修改后必须重启MySQL服务才能生效，重启后用CREATE USER建的用户就会自动采用配置里的插件，除非建用户时显式用IDENTIFIED WITH指定其他插件。这个方式适合整个环境都是老驱动的场景，但它不会改动已经存在的用户，因此常和前面的ALTER USER配合使用。
[mysqld] default_authentication_plugin=mysql_native_password
也可以在启动时用命令行参数覆盖，如mysqld --default-authentication-plugin=mysql_native_password，不过命令行方式重启后丢失，只适合临时排查。理解配置位置与系统表位置的区别很重要：配置文件管的是默认值与新建行为，mysql.user表管的是具体账号的当前状态。两者结合，才能完整回答MySQL身份验证方式在哪里这个问题。
复制环境与容器场景下的注意事项
在主从复制架构中，slave连接master使用的账号同样受plugin约束。如果master升级到新版本并把复制账号设成caching_sha2_password，而slave端驱动不支持，复制就会断。因此修改身份验证方式时要先检查复制账号，用前面说的SELECT语句确认plugin列。必要时把复制账号单独改成兼容插件，并保证主从两边mysql.user表关于该账号的plugin一致。
在Docker容器里跑MySQL时，配置文件往往通过挂载卷传入，身份验证默认值可以在docker run时用--default-authentication-plugin参数或挂载的my.cnf设定。容器初始化脚本创建的root及其他用户，会继承这个默认值。如果后期进容器用ALTER USER改了系统表，但容器重建时又用了旧镜像和旧脚本，改动会丢失。所以容器场景更推荐把认证配置写进挂载的配置文件，而不是只改系统表。
docker run --name mysql01 -e MYSQL_ROOT_PASSWORD=pass -v /my/custom:/etc/mysql/conf.d -d mysql:8.0 --default-authentication-plugin=mysql_native_password
综上所述，MySQL身份验证方式的位置分两层：具体账号的认证插件在mysql.user表的plugin列，服务器新建用户的默认插件在配置文件或启动参数里。掌握这两处并熟练用ALTER USER与配置项调整，就能应对绝大多数连接认证故障。
MySQLauthentication_pluginuser_management修改时间：2026-08-17 22:36:35