validate_password插件未生效的首要原因是未加载，需执行SHOW PLUGINS确认Status为ACTIVE；未加载则用INSTALL PLUGIN临时加载或在my.cnf中配置plugin_load_add永久启用。
validate_password插件没生效？先确认是否已加载
MySQL 5.7+ 自带 validate_password 插件，但默认不启用。很多配置失败的根源是插件压根没加载——不是策略写错了，是插件根本不在运行时插件列表里。
执行 SHOW PLUGINS; 查看输出中是否有 validate_password 行，Status 列为 ACTIVE 才算成功。如果没看到，说明插件未加载。
- 临时加载：运行
INSTALL PLUGIN validate_password SONAME 'validate_password.so';（Linux）或'validate_password.dll'（Windows） - 永久生效：在
my.cnf的[mysqld]段落加一行plugin_load_add = validate_password.so（注意路径和文件名需匹配你的 MySQL 版本和系统） - 加载失败常见报错：
Plugin 'validate_password' is not loaded或Can't open shared library，多半是插件文件名错误、路径不对、或 SELinux/权限拦截
密码强度不达标却还能创建用户？检查变量是否动态可改
插件加载后，必须设置几个关键系统变量才能真正起作用，比如 validate_password.length、validate_password.mixed_case_count 等。但这些变量是否能在线修改，取决于 MySQL 启动方式和配置位置。
例如，在 MySQL 8.0 中，validate_password.policy 是只读变量（READ ONLY），不能用 SET GLOBAL 修改，只能写在配置文件里重启生效；而 validate_password.length 在多数版本中支持动态设置。
- 查看当前值：
SELECT @@validate_password_length, @@validate_password_policy; - 动态设置（仅限支持的变量）：
SET GLOBAL validate_password_length = 12; - 必须重启才生效的变量（如
validate_password.policy在 8.0+）：写入my.cnf，加validate_password.policy = STRONG，然后systemctl restart mysqld - 混淆点：MySQL 5.7 的
policy值是数字（0=LOW, 1=MEDIUM, 2=STRONG），8.0+ 改为字符串（LOW/MEDIUM/STRONG），设错会静默忽略
CREATE USER 或 ALTER USER 报错 ERROR 1819？不是密码问题，是校验逻辑触发了
这个错误信息 ERROR 1819 (HY000): Your password does not satisfy the current policy requirements 是插件介入的明确信号，但它不一定代表你输的密码“弱”，更可能是策略和实际输入之间存在隐式冲突。
Word报告自动生成神器。自动生成专业Word文档报告，支持模板填充、目录生成、表格/图表插入、页眉页脚、多级标题、样式主题、批量邮件合并。当用户需要生成Word报告、创建合同文档、批量生成通知/证书、填充Word模板、制作商业计划书时触发。
典型陷阱是：MySQL 会自动把空格、引号、反斜杠等字符计入长度校验，但客户端（尤其是某些 GUI 工具或 shell）可能提前截断或转义，导致你认为输对了，其实传给服务端的密码不符合长度或字符类要求。
- 测试最简场景：用
mysql -u root -p命令行直连，执行ALTER USER 'test'@'localhost' IDENTIFIED BY 'Aa1234567890';（12位，大小写+数字） - 避免在密码中使用
#、;、空格等 shell 元字符，否则命令行可能提前截断 - 若用脚本批量建用户，确保密码字符串被单引号完整包裹，且未被模板引擎（如 Ansible/Jinja）意外替换
- 插件默认禁用字典检查（
validate_password.dictionary_file为空），但如果设了自定义词典，含常见单词的密码会直接拒绝，哪怕长度达标
升级 MySQL 后策略失效？注意版本间变量名和默认值变化
MySQL 5.7 和 8.0 对 validate_password 的实现差异不小，升级后旧配置可能被忽略或行为突变。最常踩的坑是变量名变更和默认策略收紧。
比如 MySQL 8.0.4+ 默认启用了 validate_password 插件，并将 validate_password.policy 默认设为 MEDIUM（5.7 默认是 LOW），同时新增了 validate_password.number_count 等更细粒度控制，但旧配置里没设这些，就容易出现“明明没动配置，密码却突然不通过”的情况。
- 升级前查清当前变量：
SELECT variable_name, variable_value FROM performance_schema.global_variables WHERE variable_name LIKE 'validate%'; - 8.0+ 推荐显式声明所有策略项，避免依赖默认值，例如补全：
validate_password.number_count = 1、validate_password.special_char_count = 1 -
validate_password.check_user_name在 8.0 默认为ON，会禁止密码包含用户名，老账号迁移时容易触发 ERROR 1372
插件本身不难配，难的是它和 MySQL 版本、启动方式、客户端环境这三者的咬合点太多。一个变量设错、一行配置漏加、一次重启没做，都可能导致策略“看起来开了，实则形同虚设”。
