mysql 5.6升级5.7后发现密码策略变严格怎么办_修改validate

mysql 5.7默认启用validate_password插件且策略为medium，导致alter user或set password报错1819；需通过set global临时调低策略（如validate_password_policy=0、length=4等）或在my.cnf中永久配置并重启服务方可使用简单密码。

mysql 5.6升级5.7后发现密码策略变严格怎么办_修改validate_password

MySQL 5.6 升级到 5.7 后，ALTER USER 或 SET PASSWORD 突然报错 Error 1819: Your password does not satisfy the current policy requirements，不是密码写错了，是插件在拦你——validate_password 插件默认启用且策略为 MEDIUM，必须主动调整才能用回习惯的密码。

确认 validate_password 插件是否已加载并生效

升级后不一定自动启用该插件，但多数 RPM/DEB 包安装的 5.7 默认已加载。先验证：

执行 SHOW PLUGINS;，查找 validate_password 行，Status 为 ACTIVE 才说明真正在运行
如果没看到，再查变量：SHOW VARIABLES LIKE 'validate_password%'; —— 若返回空结果，插件未加载，跳过后续策略修改，直接改密码即可
若变量有返回但 validate_password_policy 是空或 OFF，可能是配置里写了 validate_password=off，此时策略实际不生效

临时绕过策略：用 SET GLOBAL 快速调低要求

适用于开发机、CI 容器、本地测试等非生产场景，重启后失效，但够用：

先设策略等级为最低：SET GLOBAL validate_password_policy = 'LOW';（或 = 0）
再放宽长度限制：SET GLOBAL validate_password_length = 4;（不能设为 0，最小支持值为 1）
其他参数可一并清零避免干扰：SET GLOBAL validate_password_mixed_case_count = 0;、SET GLOBAL validate_password_number_count = 0;、SET GLOBAL validate_password_special_char_count = 0;
执行完立刻试改密码：ALTER USER 'root'@'localhost' IDENTIFIED BY '123456';

注意：SET GLOBAL 只影响当前会话之后的新连接，已存在的连接不受影响；且这些设置在 MySQL 重启后丢失。

永久禁用或降级：改 my.cnf 配置文件

想一劳永逸，必须写入配置文件。编辑 /etc/my.cnf（或 /etc/mysql/my.cnf），在 [mysqld] 段下添加：

Word Mail Merge Template Workflow

构建并排查Microsoft Word邮件合并及DOCX模板工作流，使用合并域、内容控件、文档属性、重复区块、数据等

下载

validate_password_policy = LOW
validate_password_length = 4
validate_password_mixed_case_count = 0
validate_password_number_count = 0
validate_password_special_char_count = 0

或者更彻底地直接禁用插件（仅限可信内网环境）：

validate_password = off

⚠️ 关键点：加完配置后必须重启 MySQL（systemctl restart mysqld），否则不生效；且 validate_password = off 会从 SHOW PLUGINS 中彻底移除该插件，SHOW VARIABLES LIKE 'validate_password%' 将无任何返回。

为什么 update mysql.user 表直接赋 authentication_string 不推荐

有人尝试绕过密码策略，直接更新 mysql.user 表的 authentication_string 字段（比如填入旧版 PASSWORD('123') 的哈希值），虽然技术上可能成功，但存在明显隐患：

MySQL 5.7 默认认证方式已从 mysql_native_password 切换为 caching_sha2_password（尤其在 8.0+ 更强制），硬写旧哈希可能导致登录失败
直接操作系统表绕过权限校验逻辑，容易遗漏 FLUSH PRIVILEGES;，导致缓存未刷新、新密码不生效
部分部署（如 Percona、MariaDB 分支）对 authentication_string 格式校验更严格，写错格式会直接拒绝连接
审计和自动化运维工具依赖标准密码变更流程，手工改表会破坏一致性

真正需要“跳过策略”的时候，优先走插件配置或 SET GLOBAL 调整，而不是碰系统表。

最易被忽略的一点：即使你把所有 validate_password_* 参数都设成 0，只要 validate_password_policy 还是 MEDIUM 或 STRONG，MySQL 仍会按对应等级做校验——参数不会自动继承策略等级，必须显式设置策略值本身。