MySQL 8.0+默认安装但未启用validate_password插件，需执行INSTALL PLUGIN启用；启用后通过validate_password.length和policy等变量控制密码复杂度，且必须写入my.cnf持久化。
MySQL 8.0+ 如何启用并配置 validate_password 插件
MySQL 8.0 默认已安装 validate_password 插件，但不自动启用；5.7 需手动安装。未启用时，validate_password.length 等变量查不到或显示为 OFF。
启用方式（需有 SUPER 权限）：
INSTALL PLUGIN validate_password SONAME 'validate_password.so';
验证是否生效：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'validate_password';
- 若返回
ACTIVE，说明插件已加载成功 - 若报错
Plugin 'validate_password' is disabled，检查my.cnf中是否含plugin_load_add = validate_password.so且未被注释 - 插件启用后，所有新设/修改的密码（包括
CREATE USER、ALTER USER、SET PASSWORD）都会校验
关键策略参数：validate_password.length 和 validate_password.policy
这两个是控制复杂度的核心变量。它们不是“开关”，而是协同生效的组合：
-
validate_password.length：最小长度，最低为 4（即使设为 3，实际也按 4 处理） -
validate_password.policy：取值LOW/MEDIUM/STRONG，决定是否检查大小写字母、数字、特殊字符 -
MEDIUM是常用平衡点：要求 ≥length，且包含大小写字母 + 数字 + 至少 1 个特殊字符 -
STRONG还会校验字典词（依赖validate_password.dictionary_file），线上极少启用
设置示例（动态生效，无需重启）：
SET GLOBAL validate_password.length = 10;<br>SET GLOBAL validate_password.policy = MEDIUM;
注意：GLOBAL 设置只对新连接生效；已有连接的会话级变量仍为旧值，但密码修改操作始终走全局策略。
为什么 ALTER USER ... IDENTIFIED BY 仍能设弱密码？
常见现象：明明设置了 validate_password.length = 12，执行 ALTER USER 'u'@'%' IDENTIFIED BY '123' 却没报错。
原因有三：
- 用户当前已存在，且 MySQL 认为该操作是“重用旧密码逻辑”——仅当显式使用
PASSWORD EXPIRE或密码过期后首次登录改密，才强制触发策略 - 执行语句的账户本身没有
SYSTEM_VARIABLES_ADMIN权限，导致策略变量读取失败（表现为静默跳过校验） - 客户端连接时使用了
--skip-secure-auth或旧协议（如 MySQL 5.6 客户端连 8.0 服务端），可能绕过插件链
验证方式：用同一用户在新连接中执行 SET PASSWORD = '123';，此时会明确报错 Your password does not satisfy the current policy requirements。
生产环境配置建议与易忽略点
不要只改 GLOBAL 变量，必须写入配置文件，否则重启失效：
[mysqld]<br>validate_password.length = 10<br>validate_password.policy = MEDIUM<br>validate_password.mixed_case_count = 1<br>validate_password.number_count = 1<br>validate_password.special_char_count = 1
几个硬伤要注意：
-
validate_password对root@localhost本地账户无效（除非显式指定plugin为caching_sha2_password并禁用 unix_socket） - 使用
mysql_native_password认证的用户，插件校验仍生效，但某些老客户端（如 PHP 5.6 mysqli）可能因协议不兼容直接断连 - 策略不作用于复制账号（
REPLICATION SLAVE）、系统账号（如mysql.infoschema）或通过authentication_ldap_sasl外部认证的用户
最常漏掉的是：策略只管“设密码动作”，不管“密码是否被泄露”。它不能替代定期轮换、禁止明文传输、限制登录 IP 等纵深防御措施。
