MySQL 8.4 authentication_policy 怎么规划账号认证：插件顺序、兼容窗口与登录验收

线上把 MySQL 从旧版本升级到 8.4 后，最容易被忽略的不是创建账号，而是“这个账号到底用哪一种认证方式”。服务端默认策略、账号显式指定的插件、客户端驱动版本，三者只要有一个没对齐，就可能出现新账号能登录、旧应用却在发布后报认证错误的情况。MySQL 8.4 的 authentication_policy 适合用来先定规则，再按账号类型做兼容验证。

更稳的做法是把 caching_sha2_password 作为新账号的默认方向，保留旧客户端的短兼容窗口；策略修改后，必须用真实驱动建立连接，并核对 mysql.user 中的认证插件。

先把 authentication_policy 看成账号创建规则

authentication_policy 约束的是 CREATE USER 和 ALTER USER 可以声明哪些认证因子。它不是一次性把所有历史账号重写的开关，已经存在的账号仍要单独查看 mysql.user.plugin。因此排查时要分成两条线：新账号遵守什么策略，旧账号当前实际使用什么插件。

初始化：先记录服务端策略和历史账号

先在测试环境核对MySQL版本和当前生效的认证策略。不用急着马上改全局参数，先把当前的配置结果备份留底，后面真出现客户端登录失败的情况，就能快速排查问题是来自策略变更还是驱动本身不兼容。

SELECT VERSION();
SHOW VARIABLES LIKE 'authentication_policy';
SELECT user, host, plugin
FROM mysql.user
ORDER BY user, host;

重点看三件事：服务器是否确实是 8.4；策略是否仍为预期值；应用账号是否还依赖已弃用的 mysql_native_password。MySQL 官方文档把这个插件列为 deprecated，迁移时应把它视为兼容债务，而不是新账号的默认选择。

编写账号策略：新账号默认走 caching_sha2_password

普通应用账号可以让数据库按照预设策略自动选择首认证因子，也可以在账号迁移的SQL脚本里显式指定认证插件，避免不同测试环境、生产环境的配置差异带来的预期外问题：

CREATE USER 'report_app'@'10.%'
  IDENTIFIED WITH caching_sha2_password BY 'replace-with-a-local-secret';
GRANT SELECT ON report_db.* TO 'report_app'@'10.%';

示例中的密码只是占位文本，不能直接放进仓库或部署日志。真正上线时从密钥管理系统注入，并把账号权限与认证方式分开审核。若要启用多因素认证，先在预发布环境用明确的 authentication_policy 验证 CREATE USER 语句是否符合预期，再安排应用改造。

运行检查：用实际客户端做兼容矩阵

光在服务端查询账号认证信息正常，不代表上层业务应用一定能正常连接。至少要分别用当前生产在用的驱动版本、历史遗留的旧版本驱动各做一轮验证，覆盖普通查询、连接池自动重连、密码轮换后新建连接这几个核心场景，记录下客户端库版本、TLS配置、返回的错误码，还有账号实际绑定的认证插件信息。

SELECT USER(), CURRENT_USER(), @@version, @@authentication_policy;
SELECT user, host, plugin
FROM mysql.user
WHERE user IN ('report_app', 'legacy_app');

如果只有旧应用失败，先核对它是否支持 caching_sha2_password 以及当前 TLS/RSA 连接条件。不要为了让一条旧连接立刻恢复，就把全局策略改回旧插件；更安全的做法是给旧账号保留短暂兼容窗口，完成驱动升级后再回收。

扩展实验：把回退边界写进迁移单

账号迁移清单里至少要包含账号归属、对应关联的应用、客户端驱动版本、当前在用的认证插件、目标认证插件、验证完成时间、对应故障回退操作这几项。单个账号验证失败的时候，只单独回退这个账号的配置或者暂停它的切换流程就行，没必要把全量账号的认证配置全部还原。针对最高权限的管理账号，提前准备好本地带外登录的方案，避免调整认证策略后直接把管理员锁在数据库外面。

• 新账号创建失败：先核对策略里允许的认证因子数量，还有配置里的插件匹配顺序。
• 旧客户端报认证错误：逐行核对驱动的支持能力、TLS/RSA配置条件，还有账号实际绑定的认证插件。
• 连接池偶发连接失败：先清空连接池里留存的旧连接，确认新创建的连接全部走的是目标认证方式。
• 升级后账号消失或者权限异常：从之前的账号变更记录里恢复配置，不要临时放宽全局权限应急。

常见问题：authentication_policy 修改前后怎么判断

修改 authentication_policy 会自动改掉历史账号吗？

这个全局策略不会自动把存量历史账号的认证插件全部重写。它的约束范围仅限新账号创建、现有账号属性修改的语句；存量历史账号还是需要手动查询它们当前实际绑定的认证插件，再逐个做迁移调整。

caching_sha2_password 一定要求 TLS 吗？

不要简单把这个插件的要求理解成“必须强制走TLS连接”。实际最终生效的连接方式、客户端本身的支持能力、数据库服务器有没有配置好安全的密钥交换条件都会影响认证结果，一定要用和生产完全同版本的驱动做实测，不能只靠账号插件的名字就下判断。

还可以继续使用 mysql_native_password 吗？

旧账号可能短期内需要兼容旧客户端，但mysql_native_password这个插件在MySQL 8.4版本已经被标记为弃用，新上线的账号不要再继续使用它，同时要给旧客户端升级、存量账号迁移设定明确的截止时间，避免兼容包袱越背越重。

清理与上线前总结

删除实验账号、撤销临时授权，再复查 mysql.user 和应用连接日志。最终验收不只看变量值，而是同时满足：策略符合设计、账号插件符合清单、新旧客户端连接结果可解释、回退路径有人实际走过一遍。