在CentOS 7环境中完成MySQL安装后，用户认证插件决定了客户端如何校验用户密码，也决定了服务端以何种哈希算法存储登录凭证。不同MySQL版本及不同安装方式下的默认认证插件并不完全一致，如果配置不当，很可能出现账号密码正确但连接被拒绝的情况。因此，理解常见插件类型、掌握查询与变更方法，以及通过配置文件统一默认策略，是数据库运维和开发人员排查连接问题的基础。
一、认识MySQL的常见认证插件
MySQL支持多种用户认证插件，其中使用范围最广的是mysql_native_password与caching_sha2_password。mysql_native_password基于SHA1哈希并加入随机盐进行校验，优点是几乎所有历史客户端和数据库驱动都能识别；caching_sha2_password则采用SHA256算法，并引入服务端缓存机制以提高认证性能，安全性明显更强，但部分旧版PHP、Python等语言驱动无法直接识别。
在CentOS 7上通过官方YUM源安装的MySQL 5.7通常默认使用mysql_native_password，而通过第三方仓库或更高版本安装的MySQL则可能默认启用caching_sha2_password。开始修改前，应先登录MySQL并查询mysql.user系统表，确认每个用户当前的插件类型，这能避免误操作或遗漏账号。
SELECT user, host, plugin FROM mysql.user;
二、创建用户时直接指定认证插件
如果需要新建数据库账号，最稳妥的方式是在CREATE USER语句中通过IDENTIFIED WITH子句显式声明认证插件。这样做可以避免后续再执行变更操作，也便于在自动化脚本中固化账号配置，减少不同环境之间因为默认插件不同而产生的差异。
指定插件时，密码需要符合对应插件的要求。例如mysql_native_password对明文密码长度没有额外限制，而caching_sha2_password在非TLS连接下依赖RSA密钥交换或明文口令传递，因此客户端必须支持对应的认证流程。下面示例分别演示了使用两种插件创建用户。
-- 使用mysql_native_password创建本地应用用户 CREATE USER 'appuser'@'localhost' IDENTIFIED WITH mysql_native_password BY 'StrongPass123'; -- 使用caching_sha2_password创建来自指定网段的用户 CREATE USER 'appuser2'@'192.168.0.1' IDENTIFIED WITH caching_sha2_password BY 'StrongPass123';
三、修改已有用户的认证插件
对于已经存在但插件类型不符合要求的用户，可以使用ALTER USER命令完成变更。这种场景常见于数据库升级或系统迁移之后，例如从MySQL 5.7升级到8.0后，老用户仍保留旧的mysql_native_password，而业务要求统一使用更安全的caching_sha2_password。
执行ALTER USER并重新设置密码后，服务端会按照新插件的规则重新计算并存储密码哈希。修改完成后，建议执行一次FLUSH PRIVILEGES。虽然多数情况下ALTER USER会自动刷新权限，但在CentOS 7的某些MySQL小版本中，显式刷新可以确保变更立即加载到内存中的权限结构。
-- 修改已有用户的插件并重置密码 ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'NewStrongPass456'; FLUSH PRIVILEGES;
四、通过配置文件统一默认插件策略
如果希望后续创建的所有用户都默认采用某个认证插件，可以修改MySQL服务端的配置文件。在CentOS 7中，主配置通常位于/etc/my.cnf，也可以使用/etc/my.cnf.d/目录下的独立配置文件。添加default_authentication_plugin参数后，需要重启MySQL服务才能生效。
需要注意，修改默认插件并不会影响已经存在的用户，只会对之后新创建的用户产生作用。如果服务端使用的是MySQL 8.0，而客户端大量依赖旧的PHP或Python数据库扩展，建议将默认值调整为mysql_native_password，以降低连接失败的概率。以下配置片段展示了如何设置，修改完成后通过systemctl重启服务。
[mysqld] default_authentication_plugin=mysql_native_password
# 重启MySQL服务使配置生效 systemctl restart mysqld
五、验证配置结果与进行连接测试
完成配置后，应当从服务端内部和客户端外部两个维度进行验证。内部验证可以再次查询mysql.user表，确认目标用户的plugin字段已经更新；外部验证则需要使用对应的数据库驱动或命令行客户端实际连接，观察是否出现与认证插件相关的报错。
使用命令行客户端连接时，如果提示caching_sha2_password不支持，可以临时使用支持该插件的新版客户端进行测试，也可以根据错误信息判断是否需要升级驱动或调整插件。下表对比了两种常见插件的兼容性与安全特性，便于在不同业务场景下选择。
| 插件名称 | 默认版本 | 客户端兼容性 | 安全特性 |
|---|---|---|---|
| mysql_native_password | MySQL 5.7 | 几乎所有旧客户端 | SHA1加盐，较弱 |
| caching_sha2_password | MySQL 8.0 | 需新驱动支持 | SHA256加缓存，强 |
六、配置中的常见误区与维护建议
一个常见的误区是认为修改服务端默认插件后，所有老用户会自动切换为新插件。实际上，配置参数只对新创建的用户生效，已经存在的用户必须逐条执行ALTER USER才能完成转换。另一个容易忽略的问题是，在Docker或远程连接场景中，认证错误有时会被误判为网络故障，因为防火墙、bind-address等网络配置同样可能拦截连接。
为了减少变更风险，建议在修改前对mysql系统库进行逻辑备份，并在测试环境中验证客户端驱动的兼容性。如果业务使用ORM框架，还应确认框架所依赖的数据库驱动版本是否支持目标认证插件，避免上线后出现大面积连接异常。
# 备份mysql系统库，便于变更前回滚 mysqldump -u root -p --single-transaction mysql > mysql_backup.sql
总体来看，MySQL用户认证插件的配置并不复杂，但涉及用户创建、用户修改、服务端默认值以及客户端兼容性等多个环节。日常运维中应当先查询确认现状，再根据业务客户端情况选择合适的插件类型；批量变更前做好备份和测试，并关注旧用户不会因全局配置变化而自动迁移这一关键细节。只有在服务端和客户端两侧同时匹配插件能力，才能保证数据库连接稳定可靠。
MySQLauthentication_pluginCentOS_7修改时间：2026-08-04 12:30:19