MySQL 8.0密码策略修改本质是配置validate_password插件全局参数，不支持用户级定制；需先确认插件已ACTIVE加载（查PLUGINS表），再SET GLOBAL调整policy及配套参数，并写入my.cnf持久化。
MySQL 8.0 修改用户密码策略，本质就是操作 validate_password 插件（或组件）的运行时参数。它不支持按用户单独设策略，所有修改都是全局生效的；改完不重启 MySQL 就能立刻约束后续的 ALTER USER 或 CREATE USER 操作。
怎么确认 validate_password 插件是否真在运行
很多问题其实卡在“以为启用了，其实没加载”。不能只看配置文件有没有那行，得查 MySQL 实际状态：
-
SHOW VARIABLES LIKE 'validate_password%';—— 如果返回空，说明插件根本没加载，SET GLOBAL任何参数都会报错Unknown system variable -
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'validate_password';—— 返回ACTIVE才算真正就位；若为DISABLED或无结果，需先执行INSTALL PLUGIN validate_password SONAME 'validate_password.dll';（Windows）或'validate_password.so';（Linux） - phpEnv 用户注意：
my.ini中的plugin-load-add=validate_password.dll必须写在[mysqld]段下，且改完后必须通过 phpEnv 界面「停止→启动」MySQL，不能只靠服务重启
为什么 SET GLOBAL validate_password.policy = LOW 还是报 ERROR 1819
因为 policy 只是总开关，真正起效的是背后四个硬性参数。设成 LOW 后，mixed_case_count、number_count 等仍可能保留旧值（比如还是 1），导致校验未真正放宽：
- 必须显式重置依赖参数：
SET GLOBAL validate_password.length = 6;、SET GLOBAL validate_password.mixed_case_count = 0;、SET GLOBAL validate_password.number_count = 0;、SET GLOBAL validate_password.special_char_count = 0; - 顺序很重要：先设
policy = LOW，再设其他参数；如果先设了mixed_case_count = 1再切到LOW，MySQL 不会自动清零，仍会校验大小写 - 验证是否生效：执行
SELECT @@validate_password_length, @@validate_password.policy;，确认返回值是你刚设的数字和等级
ALTER USER 改密码时绕过强度检查的唯一可靠方式
即使调低了全局策略，某些场景下（如用户原用 caching_sha2_password 认证）仍可能触发校验失败。最稳妥的做法不是“降策略”，而是显式指定认证方式并提供兼容哈希：
- 用
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '123456';—— 强制走老式认证，跳过validate_password对明文的校验逻辑 - 该方式对已存在的用户有效，且不依赖策略参数是否归零；但注意：
mysql_native_password安全性低于默认的caching_sha2_password，仅建议开发环境临时使用 - 生产环境不要禁用插件或设
policy = 0，而应配合validate_password.dictionary_file拦截常见弱口令，这才是真实可用的加固路径
真正容易被忽略的是：所有 SET GLOBAL 设置在 MySQL 重启后全部丢失，必须写入 my.ini（Windows）或 my.cnf（Linux）的 [mysqld] 段才能持久化；而 phpEnv 用户常误以为改了配置就完事，忘了手动重启 MySQL 进程——它不走 Windows 服务，停启必须点界面或跑 mysql-stop.bat + mysql-start.bat。
