MySQL 8.0 默认启用的 validate_password 插件策略过松（仅校验长度≥8），需在 my.cnf 的 [mysqld] 段配置 plugin_load_add=validate_password.so，并设置 length、mixed_case_count、number_count、special_char_count 四个参数才能生效；dictionary_file 需绝对路径、权限正确且重启加载，否则无效。
MySQL 8.0 默认启用了 validate_password 插件，但策略太松？
默认情况下，MySQL 8.0 安装后会自动加载 validate_password 插件，但它的默认策略（low）只检查密码长度 ≥8，基本等于没设防。你改了 validate_password.policy 却发现不起作用？大概率是插件根本没真正启用，或者配置写在了错误位置。
- 确认插件是否已加载：
SELECT plugin_name, plugin_status FROM information_schema.plugins WHERE plugin_name = 'validate_password';—— 若返回空或DISABLED，说明没生效 - 插件必须在 MySQL 启动时加载，仅靠
INSTALL PLUGIN可能不持久；推荐在my.cnf的[mysqld]段落里加：plugin_load_add = validate_password.so
- 配置项必须写在
[mysqld]下，写在客户端段落或运行时用SET GLOBAL设置，重启后就丢失
validate_password 的四个关键参数怎么配才有效
光设 validate_password.policy 不够，它只是“策略等级”，真正起作用的是背后四个硬性参数。比如设成 MEDIUM，但若 validate_password.length 还是默认 8，那带大小写字母+数字+符号的 12 位密码照样通不过——因为长度卡死了。
-
validate_password.length：最小长度，MEDIUM策略下建议 ≥12 -
validate_password.mixed_case_count：至少几个大小写字母组合（不是指大小写都要有，而是“混合字符数”），建议 ≥1 -
validate_password.number_count：至少几个数字，建议 ≥1 -
validate_password.special_char_count：至少几个特殊字符（如!@#$%），建议 ≥1；注意：MySQL 自带字典只认 ASCII 特殊字符，中文符号、emoji、全角标点无效
为什么设置了 validate_password.dictionary_file 却没生效
想禁用常见弱口令（比如 password123 或公司名）？dictionary_file 是唯一办法，但它极容易踩坑：路径权限、文件格式、加载时机三者缺一不可。
- 文件路径必须是 MySQL 进程有读取权限的绝对路径（如
/etc/mysql/weak-passwords.txt），不能是相对路径或用户家目录 - 每行一个单词，不能有空格、注释或空行；文件末尾必须换行，否则最后一行可能被忽略
- 必须在插件加载后、且 MySQL 重启前设置该参数；运行时执行
SET GLOBAL validate_password.dictionary_file = '/path/to/file';不会触发重新加载，得手动执行SET GLOBAL validate_password.check_user_name = ON;才会重新读取（但不保证稳定） - 开启后，密码若包含字典中任意子串（不分大小写、不区分边界）就会被拒绝，比如字典含
abc，则123abc456也会失败
ALTER USER 报错 Failed to set password for 'xxx': Password validation failed 怎么快速定位
这个错误不是密码输错了，而是当前 session 或全局的验证策略比你预期更严。尤其当管理员改了策略，而你的客户端还连着旧连接，或者用了旧版本 MySQL Shell，容易误判。
- 先查当前生效值：
SELECT @@validate_password_policy, @@validate_password_length, @@validate_password_mixed_case_count;—— 注意用@@查全局，不是@ - 如果用
mysql_native_password认证方式，某些老客户端（如 MySQL Workbench 8.0 以下）可能把密码预处理成哈希再传，导致校验逻辑异常；建议临时切到caching_sha2_password测试 - 开发环境调试时，可临时降级策略：
SET GLOBAL validate_password.policy = LOW;，但别在线上长期这么干 - 最隐蔽的坑：某些运维脚本用
mysql -e "ALTER USER ..."执行，但未指定--defaults-file，导致读不到my.cnf里的插件配置，从而走默认策略
策略调得越严，越要小心自动化工具和备份恢复流程——比如 mysqldump 的 --set-gtid-purged 或主从切换脚本里硬编码的密码，可能突然就过不了验证。每次调参后，务必用实际建用户 + 改密流程跑一遍端到端验证。
