validate_password插件未加载最常见原因是配置后未重启或插件文件缺失，需查plugin_dir路径下so/dll文件是否存在，并在my.cnf中正确配置plugin_load_add=validate_password.so（8.0.19+推荐install component），再执行show plugins确认状态为active。
validate_password 插件根本没加载
最常见的情况是：你改了配置、重启了 MySQL，但 SHOW VARIABLES LIKE 'validate_password%' 一条记录都查不到。这说明插件压根没加载，校验自然不触发。
检查步骤：
- 执行
SELECT @@plugin_dir;确认插件路径，然后去对应目录下看是否存在validate_password.so（Linux）或validate_password.dll（Windows） - 在
my.cnf的[mysqld]段里必须写plugin_load_add = validate_password（MySQL 8.0.19+ 推荐用INSTALL COMPONENT，但配置文件方式更稳） - 执行
SHOW PLUGINS;，确认validate_password状态是ACTIVE，不是DISABLED或缺失
MySQL 5.7 默认不启用，8.0 虽默认内置，但若配置文件里写了 skip-grant-tables 或显式禁用插件，它也会静默失效。
策略参数只设了 SET GLOBAL，没写进配置文件
SET GLOBAL validate_password.policy = LOW 这类命令只对当前会话生效，且重启后丢失。如果你没在 my.cnf 里持久化配置，服务一重启就回到默认值——MySQL 8.0 默认是 MEDIUM，但若插件没加载或配置拼错（比如写成 validate_password_policy 缺少点号），实际策略可能仍是未定义状态。
必须写入配置文件的正确写法：
[mysqld] validate_password.policy = LOW validate_password.length = 6 validate_password.mixed_case_count = 0 validate_password.number_count = 0 validate_password.special_char_count = 0
注意：参数名带点号（.），不是下划线；所有参数都要在 [mysqld] 段下，不能放在 [client] 或其他段。
密码操作没走校验路径
validate_password 只在校验 CREATE USER、ALTER USER ... IDENTIFIED BY、SET PASSWORD（已弃用）时触发，它不检查已有用户密码，也不干预客户端连接过程。
典型误判场景：
- 用
UPDATE mysql.user SET authentication_string = ...直接改哈希值 → 绕过校验，但密码可能无法登录（尤其caching_sha2_password场景） - 执行
ALTER USER 'u'@'h' IDENTIFIED WITH mysql_native_password BY '123'→ 若插件策略为STRONG且字典文件不可读，会失败；但若插件根本没加载，这条反而能成功 - 用旧版 JDBC 驱动连
caching_sha2_password用户 → 客户端握手失败，看起来像“密码没生效”，其实是认证插件不兼容
STRONG 策略下字典文件缺失或不可读
设 validate_password.policy = STRONG 后，MySQL 要求 validate_password.dictionary_file 必须指向一个真实存在、MySQL 进程可读的文件。否则插件初始化失败，整个组件可能退回到未启用状态——此时 SHOW VARIABLES LIKE 'validate_password%' 仍返回变量，但校验逻辑不运行。
验证方法：
- 执行
SELECT VALIDATE_PASSWORD_STRENGTH('123456');，如果返回NULL或报错，说明组件异常 - 检查错误日志：
tail -n 20 /var/log/mysql/error.log，搜索dictionary_file或validate_password相关警告 - 确保文件权限：MySQL 用户（通常是
mysql）能读取该文件，且路径不能是符号链接（部分版本不支持）
真正卡住的地方往往不是策略设得太严，而是你调高了 policy 却忘了配字典，或者配了却没给权限——MySQL 不会主动报错，只会沉默跳过校验。
