插件未加载是密码策略失效的主因，需先执行install plugin并验证information_schema.plugins；配置文件参数名须全小写、下划线分隔、无点号；strong策略需指定有效字典文件路径且mysql进程有读权限；策略仅作用于create/alter user ... identified by语句。
插件没加载，所有配置都白设
直接执行 SET GLOBAL validate_password_length = 8 却发现没效果？先别调参数——90% 的问题出在插件根本没加载。MySQL 5.7 默认不启用 validate_password，SHOW VARIABLES LIKE 'validate_password%' 返回空结果就是铁证。
确认方式只有一条：运行 SELECT * FROM information_schema.plugins WHERE plugin_name = 'validate_password';。如果没返回任何行，说明插件未安装或未激活。
- 加载命令必须用
INSTALL PLUGIN validate_password SONAME 'validate_password.so';（Linux/macOS）或'validate_password.dll'（Windows） - 加载后立即查
information_schema.plugins表，不能只信SHOW PLUGINS——后者可能显示状态为 ACTIVE 但实际未生效 - 加载失败常见原因是
plugin_dir路径不对，可查SELECT @@plugin_dir;确认路径是否存在validate_password.so文件
配置文件里参数名写错就等于没配
my.cnf 中写 validate_password.policy = MEDIUM 或 validate_password_length=12？全无效。5.7 配置文件要求严格使用下划线+小写格式，且不能带点号。
正确写法只有一种：validate_password_length、validate_password_policy、validate_password_number_count……全部小写、下划线分隔、无点号。
-
validate_password_policy值填数字（0/1/2）或字符串（LOW/MEDIUM/STRONG），推荐用数字，避免大小写敏感问题 -
validate_password_length有硬性下限：必须 ≥validate_password_number_count+validate_password_special_char_count+ 2 ×validate_password_mixed_case_count，否则启动报错 - 改完 my.cnf 必须重启 MySQL，
SET GLOBAL只影响当前实例，重启即丢失
STRONG 级别不配字典文件，实际就是 MEDIUM
设了 validate_password_policy = 2 却发现弱密码还是能过？因为 STRONG 级别强制校验字典文件，而默认 validate_password.dictionary_file 是空字符串，插件会跳过字典检查，退化为 MEDIUM 行为。
在 Proxmox VE 上创建 Ubuntu 24.04 LXC 容器或完整虚拟机，兼容 Docker‑ready 与 Compose v2，处理 Docker‑in‑LXC 嵌套，自动选择下一个可用的 CTID。
要真正启用 STRONG，必须指定一个有效路径并确保文件可读：
- 先创建字典文件，比如
/etc/mysql/password_dict.txt，每行一个禁止词（如password、admin、mysql） - 在 my.cnf 中加一行：
validate_password_dictionary_file = /etc/mysql/password_dict.txt - MySQL 进程必须有该文件的读权限（非 root 启动时尤其注意）
- 验证是否生效：执行
SELECT @@validate_password_dictionary_file;，返回路径不为空且可访问才算成功
策略只在 CREATE/ALTER USER 时触发，不扫旧账号
很多人启用后立刻去试 ALTER USER 'root'@'localhost' IDENTIFIED BY '123456'; 报错，就以为策略生效了；但反过来用 SET PASSWORD FOR 'root'@'localhost' = '123456'; 却成功——这是对作用边界的误解。
validate_password 插件只介入以下两类语句：
CREATE USER ... IDENTIFIED BYALTER USER ... IDENTIFIED BY
它完全不拦截 SET PASSWORD、不校验初始 root 密码、也不重检已存在用户的密码强度。另外，validate_password_check_user_name = ON（默认）还会拒绝用户名作为密码子串，比如用户叫 app_user，密码含 app_user 就会被拦。
最易被忽略的一点：远程用户创建失败常被归因为网络或权限，其实八成是密码不满足策略，错误码固定为 ERROR 1819 (HY000)，看到这个就该先查策略是否真启用了。
