alter user后应用仍连不上，主因是客户端连接池未重建且驱动不支持新认证插件；需重启应用或连接池，并确认驱动版本兼容caching_sha2_password。
直接改密码不等于业务无感知。MySQL 8.0+ 中，ALTER USER 本身是原子操作，但若账号正被应用连接池持有、或密码策略变更触发认证插件切换，就可能造成连接中断或登录失败。
ALTER USER 执行后为什么应用仍连不上？
常见现象是执行完 ALTER USER 'appuser'@'%' IDENTIFIED BY 'newpass123!'; 并 FLUSH PRIVILEGES; 后，Java 应用报 Access denied for user 或 Python 报 Authentication plugin 'caching_sha2_password' cannot be loaded。
- 根本原因不是权限没刷新，而是客户端连接池未重建——旧连接仍用老密码握手，而新连接尝试时，服务端已启用新认证插件（如从
mysql_native_password切到caching_sha2_password），但客户端驱动不支持或未配置对应插件 - MySQL 8.0 默认使用
caching_sha2_password，但很多老版本 JDBC（ -
FLUSH PRIVILEGES;在 MySQL 8.0+ 中其实已非必需，权限变更由ALTER USER自动生效；加了也不会修复插件不匹配问题
如何避免改密码导致业务抖动？
核心思路：让新密码“渐进生效”，而非“一刀切换”。
- 先为同一账号创建第二个主机粒度的凭据，例如已有
'appuser'@'10.10.20.%'，再新增'appuser'@'10.10.20.%'（同名同主机，但密码不同）——不行，MySQL 不允许重复账号；正确做法是新增一个带版本标识的账号，如'appuser_v2'@'10.10.20.%'，并赋予完全相同权限 - 在应用侧灰度切换连接串：先切 5% 流量到新账号，验证连接、查询、事务是否正常；确认无误后再全量切流
- 如果必须复用原账号名，可在改密码前先显式指定认证插件，确保兼容性：
ALTER USER 'appuser'@'%' IDENTIFIED WITH mysql_native_password BY 'newpass123!';（适用于 JDBC 5.x / PyMySQL 0.9 等旧驱动） - 切流期间保留旧账号至少 24 小时，等所有长连接自然断开或超时释放，再执行
DROP USER 'appuser_old'@'%';
密码强度变更引发的静默失败
生产环境常启用 validate_password 组件。若新密码不符合当前策略（如策略为 MEDIUM，但新密码缺特殊字符），ALTER USER 会直接报错 ERROR 1819 (HY000): Your password does not satisfy the current policy requirements ——但有些 ORM 或连接池会把这类 SQL 错误吞掉，只表现为“密码没变”。
- 执行前务必检查策略：
SELECT @@validate_password.policy, @@validate_password.length, @@validate_password.mixed_case_count; - 临时放宽策略仅限紧急场景，且必须配对恢复：
SET PERSIST validate_password.policy = LOW;→ 改密码 →SET PERSIST validate_password.policy = MEDIUM; -
SET PERSIST比SET GLOBAL更安全，它会写入 mysqld-auto.cnf，重启后依然生效，避免策略丢失
别忽略 host 匹配细节和连接来源
同一个用户名，'appuser'@'localhost' 和 'appuser'@'127.0.0.1' 是两个独立账号。线上应用通常走 TCP 连接，host 是 '10.10.20.5' 或 '%'，但你登录 MySQL 时用的是 mysql -u appuser -p -h 127.0.0.1，实际匹配到的可能是 'appuser'@'127.0.0.1'，而非应用所用的 'appuser'@'10.10.20.%'。
- 查清楚应用真实连接的 host：
SELECT user, host FROM mysql.user WHERE user = 'appuser'; - 改密码时务必精确指定 host：
ALTER USER 'appuser'@'10.10.20.%' IDENTIFIED BY 'newpass123!';，不能只写'appuser'@'%'（太宽泛，可能覆盖不该动的账号） - 若应用通过跳板机或代理连接，host 可能是代理 IP，需确认网络路径后的真实来源地址
最易被忽略的一点：密码修改后，连接池里的空闲连接不会自动重认证。它们仍持旧凭据，直到下次使用时才报错。这意味着故障不是立刻爆发，而是在流量高峰时集中出现。上线前务必在低峰期预热连接池，并观察监控中的连接重试率与认证失败数。
