小泉水1. 项目概述：MySQL 8.0 密码策略带来的连环坑
1.1 为什么一篇密码设置的文章值得单独写
你在本地用 MySQL 8.0 建了个测试库，执行 ALTER USER 'root'@'localhost' IDENTIFIED BY '123456';，结果系统直接甩你一个 ERROR 1819 (HY000): Your password does not satisfy the current policy requirements。再换成 root、admin、12345678 这类“看起来没问题”的短密码，依然被拒。这时候很多人第一反应是“MySQL 是不是坏了”，其实不是，是 MySQL 8.0 的默认密码策略比 5.7 严格了一大截，而你还没有掌握和它打交道的方法。
这篇内容要解决的就是这个问题：MySQL 8.0 的默认密码策略到底校验什么、怎么调整、什么时候能调、什么时候千万别动。同时把网上很少讲清楚的两个场景分开说——本地开发环境你怎么放宽策略让日子好过一点，生产环境你怎么在合规和安全之间找到平衡点。文章还会顺手覆盖 Windows 11 下 MySQL 8.0 的完整卸载与重装流程，因为我在排查密码问题时发现，很多人其实是安装过程就没弄干净，导致组件状态混乱，密码策略怎么改都不生效。
1.2 这篇文章适合谁来读
如果你符合下面任意一条，这篇文章就是写给你的：
- 刚装完 MySQL 8.0，正在被
ERROR 1819折磨的初学者 - 从 MySQL 5.7 升级到 8.0，发现之前能用的密码设置方法全部失效的老手
- 需要在本地快速起一个开发环境，不想被强密码策略拖慢节奏的开发者
- 负责维护生产数据库，想知道密码策略改了会影响哪些历史账号的 DBA 或后端工程师
我会尽量把原理讲清楚，但不会堆砌官方文档式的废话。每一步操作都给出可以直接复制的命令，同时告诉你“为什么这么写”以及“不这么写会有什么后果”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 整体设计思路：先理解策略，再破解策略
2.1 MySQL 8.0 密码组件的变化：从插件到组件
在 MySQL 5.7 时代，密码强度校验由一个叫 validate_password 的插件实现。到了 MySQL 8.0，官方把它升级成了组件（component），名字也变成了 validate_password.component。插件的加载方式是 INSTALL PLUGIN，而组件需要先执行 INSTALL COMPONENT 'file://component_validate_password' 才能使用。
这个变化直接带来一个体验差异：MySQL 8.0 安装完成后，默认启用了密码校验组件。而在 5.7 里，即使配置文件写了 validate_password=ON，也可能因为插件没正确安装而形同虚设。所以很多人从 5.7 升到 8.0 后，第一次执行 ALTER USER 就被难住了——这是正常的，因为你面对的不再是同一个机制，而是一套全新的、默认打开的安检系统。
官方在 MySQL 8.0.34 之前对组件目录的默认路径也有调整，Windows 环境下组件文件通常位于 MySQL 安装目录的 lib/plugin 文件夹中。如果你用命令行手动安装组件却发现找不到文件，十有八九是路径没配对。
2.2 默认策略的三个核心参数
MySQL 8.0 的默认密码策略由 validate_password 组件提供，所有可调参数都在 performance_schema 和系统变量中。最核心的三个参数：
| 参数名 | 默认值 | 作用 |
|---|---|---|
validate_password.length |
8 | 密码最小长度 |
validate_password.policy |
1（MEDIUM） | 校验强度：0=LOW，1=MEDIUM，2=STRONG |
validate_password.check_user_name |
ON | 禁止密码与用户名相同或包含用户名 |
这里重点解释一下 policy 的取值。LOW（0）只校验长度；MEDIUM（1）在长度之外，还要求密码必须包含数字、大写字母、小写字母中的至少两类（取决于 mixed_case_count、number_count 和 special_char_count 的设置）；STRONG（2）则在 MEDIUM 基础上，额外检查密码中是否包含字典文件里的常见弱密码片段。
你可能会问：“我设置 root123 这种密码，长度够 8 位了，为什么还是失败？”因为 check_user_name 默认开启，密码里包含了用户名 root 这个子串，直接被判定为不合格。这是我见过的最常见误区：只看长度，忽略用户名检测。
2.3 为什么这次策略“动了真格”
从 MySQL 8.0 开始，官方把默认身份认证插件从 mysql_native_password 切换成了 caching_sha2_password。新的认证插件使用 SHA-256 加密算法，对密码传输和存储都提出了更高要求。更关键的背景是，这些年数据库密码泄露事件频发，大量弱密码攻击都建立在“数据库默认密码策略宽松”的基础上。所以官方干脆把默认策略上调到 MEDIUM，并且不允许你通过简单的 my.ini 临时开关来绕过。
本地开发时你可以修改参数来放宽，但生产环境我强烈建议保持默认策略。后面会解释为什么有些人在生产环境改了密码策略，导致从库同步直接失败的惨痛案例。