validate_password插件未生效需先检查是否已加载，再确认各子规则阈值（如length、mixed_case_count）是否合理设置，且mysql 8.0起改用component机制，变量名和加载方式均变更。
validate_password 插件没生效？先确认是否已加载
MySQL 5.7+ 默认带 validate_password 插件，但不是自动启用的。很多配置写了半天没效果，是因为插件压根没装上。
- 执行
SHOW PLUGINS;查看validate_password状态是否为ACTIVE - 如果没看到，运行
INSTALL PLUGIN validate_password SONAME 'validate_password.so';（Linux）或validate_password.dll（Windows） - 插件加载后，
validate_password.policy等变量才真正可设；否则修改只是临时值，重启就丢 - 部分云数据库（如阿里云 RDS、腾讯云 CDB）默认禁用该插件，且无法手动安装——得换用平台提供的密码策略开关
policy=2 时密码仍能设成 '123456'？检查 length 和 mixed_case_count
validate_password.policy 设成 MEDIUM（即 2）只代表“启用全部校验项”，不代表所有项都开火——每个子规则还得单独配阈值。
-
validate_password.length默认是 8，低于它直接拒绝；设成 6 就可能让123456过关 -
validate_password.mixed_case_count默认是 1，但若设成 0，大小写混合就失效 -
validate_password.number_count和validate_password.special_char_count同理，默认都是 1，设成 0 就等于放行纯字母密码 - 常见误操作：只改
policy，忘了调这些 count 参数，结果策略形同虚设
ALTER USER 报错 ERROR 1819？不是密码不对，是当前用户没权限改自己
执行 ALTER USER 'u'@'%' IDENTIFIED BY 'P@ssw0rd!'; 报 ERROR 1819 (HY000): Your password does not satisfy the current policy requirements，但密码明明合规——大概率是当前会话用户没被授予 CREATE USER 或 UPDATE 权限。
- MySQL 在校验密码时，会检查执行者是否有修改用户定义的权限；没有的话，即使密码合法也会报这个错
- 用
SELECT CURRENT_USER();确认当前身份，再查SHOW GRANTS;看是否含CREATE USER或全局UPDATE - root 用户一般没问题；普通账号若仅授了
SELECT/INSERT，改密就会失败 - 临时绕过：用 root 执行
SET PASSWORD FOR 'u'@'%' = 'xxx';（但该语句在 8.0+ 已弃用，优先用ALTER USER+ 正确权限）
升级到 MySQL 8.0 后 validate_password 不见了？它被拆进 component 了
MySQL 8.0 移除了传统插件机制，validate_password 改用 component 方式加载，语法和变量名全变了，老配置直接失效。
- 加载方式变成：
INSTALL COMPONENT 'file://component_validate_password';（路径需根据实际安装位置调整） - 变量名全加了前缀：
validate_password.length→component_validate_password.length - 原
validate_password.dictionary_file在 8.0 中默认关闭，且路径必须绝对、文件需由 mysqld 可读，否则启动报错 - 8.0 的策略逻辑更严格：比如
dictionary_file匹配不仅看单词本身，还做子串检测（password会命中pass），容易误杀
最常被忽略的是：策略生效依赖于用户创建/修改的上下文权限，而不是单纯密码字符组合。调参前先跑一遍 SELECT * FROM performance_schema.variables_by_thread WHERE VARIABLE_NAME LIKE 'validate%';，看清当前会话看到的真实值。
