必须先确认validate_password组件或插件已启用，否则SET GLOBAL validate_password.policy=LOW无效；若SHOW VARIABLES LIKE 'validate_password%'无返回，需用INSTALL COMPONENT（8.0.17+）或INSTALL PLUGIN加载模块后，再按序设置policy及length等参数。
为什么 SET GLOBAL validate_password.policy = LOW 不总是生效
直接执行 SET GLOBAL validate_password.policy = LOW 后仍报 ERROR 1819，大概率是因为插件根本没加载，或者你用的是 MySQL 8.0.17+ 的组件（component）模式而非插件（plugin）模式。MySQL 8.0 默认可能只预装了组件但未启用，SHOW VARIABLES LIKE 'validate_password%' 查不到任何变量就是最明显的信号。
验证方式很简单：
- 运行
SELECT * FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'validate_password';—— 若无结果，说明插件未安装 - 运行
SELECT * FROM performance_schema.component_table WHERE component_name = 'validate_password';（8.0.17+）—— 若查不到，说明组件也未注册
这时候光设全局变量毫无意义，得先让策略模块真正“上线”。
如何正确启用 validate_password 组件（MySQL 8.0.17+）
MySQL 8.0.17 起，官方推荐用 INSTALL COMPONENT 加载密码验证组件，而不是旧的 INSTALL PLUGIN。路径必须写对，且需有 FILE 权限（root 用户通常默认具备）：
INSTALL COMPONENT 'file://component_validate_password';
成功后立刻能查到变量：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
SHOW VARIABLES LIKE 'validate_password%';
此时再设策略才有效：
-
SET GLOBAL validate_password.policy = LOW;（仅允许长度 ≥ 8） -
SET GLOBAL validate_password.length = 4;（若想进一步放宽，需先降 policy 到 LOW，否则该参数被忽略） - 注意：
validate_password.length在MEDIUM或STRONG下最小值固定为 8，无法设更低
ALTER USER 仍报错？检查 host 匹配和认证插件类型
即使策略已调低，ALTER USER 'root'@'localhost' IDENTIFIED BY '123456' 还是失败，常见原因有两个：
-
'root'@'localhost'在mysql.user表里实际不存在——真实记录可能是'root'@'%'或'root'@'127.0.0.1'，用SELECT user,host FROM mysql.user WHERE user='root';确认 - 用户当前用的是
caching_sha2_password插件，而客户端驱动不支持（比如老版 PHP mysqli），此时设再弱的密码也连不上；可临时切回兼容模式：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '123456';
切插件后务必 FLUSH PRIVILEGES;，否则新认证方式不生效。
生产环境千万别设 LOW：复杂点在于策略与连接生态的耦合
设 LOW 看似一步到位，但真正麻烦的是后续——所有连接这个库的应用、脚本、ORM、连接池（如 HikariCP、Druid）都得同步确认是否支持新策略下的认证流程。很多 Java 应用在 JDBC URL 里没加 ?allowPublicKeyRetrieval=true&useSSL=false，或驱动版本低于 8.0.16，就会在密码改完后直接连不上，错误日志里往往只显示 “Access denied”，根本看不出是认证插件不匹配。
更隐蔽的坑是：Docker 容器重启后，如果 my.cnf 没固化 validate_password 配置，组件会自动卸载，策略回归默认 MEDIUM，应用又突然失联。
