mysql如何解决授权时提示Your password does not satisfy_降低密码策略等级-mysql教程-PHP中文网

直接结论：error 1819 是 validate_password 插件的密码强度校验拦截所致，需调低策略；set global 不生效因仅当前会话有效且依赖权限，永久生效须在 my.cnf 的 [mysqld] 段配置 validate_password.policy=low 等参数并重启服务。

mysql如何解决授权时提示your password does not satisfy_降低密码策略等级

直接结论：这不是授权问题，而是密码强度校验拦截了 ALTER USER 或 CREATE USER 操作。必须先调低 validate_password 插件策略，否则任何设弱密码的操作都会被 ERROR 1819 (HY000) 拦住。

为什么 SET GLOBAL 不生效？配置没写对位置

MySQL 8.0+ 的密码策略由 validate_password 插件控制，它有两套配置方式：运行时临时设置（SET GLOBAL）和永久配置（配置文件）。但很多人漏掉关键点：

SET GLOBAL validate_password.policy = LOW 只在当前会话有效，且要求你已有足够权限（比如 root），如果连 root 都被锁死在登录环节，这句根本执行不了
配置文件中必须写在 [mysqld] 段下，且不能拼错参数名——常见错误是写成 validate_password_policy（旧版 MySQL 5.7 写法），而 MySQL 8.0+ 要求用 validate_password.policy（带点号）
插件本身可能未启用：执行 SHOW PLUGINS; 查看 validate_password 状态是否为 ACTIVE；若为 DISABLED，需先在配置文件加 plugin_load_add = validate_password.so（Linux）或 validate_password.dll（Windows）

my.cnf / my.ini 中怎么写才真正永久生效

编辑 MySQL 主配置文件（如 /etc/mysql/mysql.conf.d/mysqld.cnf 或 C:\mysql\my.ini），在 [mysqld] 下添加：

Seo Keyword Researcher

为任意主题进行SEO关键词调研，并生成完整文章摘要，包括主关键词、次关键词、竞争分析、文章结构等。

下载

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 8.0.26+ 已废弃，会导致启动失败
Windows 下路径含空格或中文时，mysqld --initialize 可能失败，建议路径全英文、无空格
改完必须重启服务：sudo systemctl restart mysql（Linux）或 net stop mysql && net start mysql（Windows）
重启后进 MySQL 执行 SHOW VARIABLES LIKE 'validate_password%';，确认所有值已更新

ALTER USER 报 ERROR 1819 但密码明明够长？检查认证插件类型

即使密码策略已调低，ALTER USER ... IDENTIFIED BY '123456' 仍可能失败，原因常是认证插件不兼容：

MySQL 8.0 默认用 caching_sha2_password，但该插件对弱密码更敏感，且部分客户端（如老版本 Navicat、某些 Python 驱动）不支持
解决办法是在同一 ALTER USER 语句中显式指定插件：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '123456';
或者全局降级默认插件：在 [mysqld] 中加 default_authentication_plugin = mysql_native_password，再重启
验证是否生效：SELECT Host, User, plugin FROM mysql.user WHERE User = 'root';，确保 plugin 列是 mysql_native_password

开发环境 vs 生产环境的取舍要点

调低策略不是“设完就完”，容易忽略的是后续行为惯性：

本地开发用 LOW + length=4 没问题，但一旦把初始化 SQL 脚本同步到测试/预发环境，别人可能照着跑出弱密码账户，且不会报错
SET GLOBAL 方式改的策略，在 MySQL 意外崩溃重启后自动恢复默认（MEDIUM），而配置文件方式才真正“永久”
如果团队共用一套 Docker Compose 启动 MySQL，记得把自定义配置挂载进去，而不是只改容器内文件——否则重建容器就回退了
最隐蔽的坑：某些云数据库（如阿里云 RDS、腾讯云 CDB）禁用了 validate_password 插件的修改权限，只能通过控制台调整参数组，命令行 SET GLOBAL 会提示 Access denied