刚装完 MySQL 8.0，很多人第一件事就是拿 root 登上去改密码。我这些年看过不少现场：在 5.7 里一路顺畅的123456，换到 8.0 直接给你甩一条ERROR 1819 (HY000): Your password does not satisfy the current policy requirements。如果你也被这句话卡住，先别急着怀疑键盘——这是MySQL 8.0 默认密码策略在起作用。这篇文章不打算只教你怎么复制粘贴命令，而是想把这个策略的前因后果、本地开发和生产环境分别该怎么处理，以及我从安装、配置到卸载重装踩过的连环坑，一次性讲透。无论你是刚入门的运维新人，还是被测试环境反复折磨的开发，照着这篇文章的思路走，基本都能顺利过关。
1. 为什么"123456"这种密码，在 8.0 里会直接吃一个 1819
1.1 先看报错现场
我用 Windows 上最常见的安装路径举例。假设你已经通过 MySQL Installer 装好了 MySQL 8.0，服务名为MySQL80，命令行工具在C:\Program Files\MySQL\MySQL Server 8.0\bin下。首次登录是拿安装过程中生成的临时密码进去的，很多教程都会让你紧接着执行：
ALTER USER 'root'@'localhost' IDENTIFIED BY '123456';然后屏幕上就出现那句经典的报错：
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements这句话翻译过来就是：你的密码不满足当前策略要求。注意，它没有告诉你"还差几位数字""缺不缺大写字母"，这是 MySQL 的懒人作风——只丢一个笼统的错误码，剩下全靠你猜。我看过有人因为这个报错反复重装 MySQL，也有人直接怀疑是安装包有问题，其实都不是，就是策略没搞明白。
1.2 5.7 到 8.0：从插件到组件，默认策略到底谁在管
在 MySQL 8.0 里，真正管密码强度的是validate_password这套机制。它最早是 5.7 时代的插件（plugin），到了 8.0 后变成了组件（component），官方从 8.0.27 开始引入组件形态，从 8.0.34 开始，官方安装包默认就把它装上了。
这解释了一个让很多人疑惑的现象：同样是 8.0，隔壁同事的机器设123456没问题，你的机器就报 1819。差别很可能在于：
- 你用的是 8.0.34 以后的官方安装包，初始化完组件默认就在运行；
- 同事用的是旧版本，或者他早前手动卸载过组件；
- 你们走的是不同的安装渠道，比如 Windows MSI、Linux RPM、Docker 镜像，默认行为的细节完全不同。
另外有个非常普遍的误解：MySQL Installer 安装过程中那个"强密码"要求，是安装器自己的校验，不是服务器策略在生效。很多人因此在安装器里被迫输了一个超复杂的密码，就误以为服务器默认策略也是它设定的。实际上，装完之后服务器里到底有没有跑validate_password，需要用命令自己确认。
1.3 检查当前策略的最快姿势
别急着猜，先上命令。用 root 登录后一次执行这三条：
SELECT * FROM mysql.component; SHOW PLUGINS; SHOW VARIABLES LIKE 'validate_password%';- 第一条能看到已经安装的组件，里面有
component_validate_password就说明组件在； - 第二条能看到插件列表里有没有
validate_password； - 第三条最直接，能查出当前实际生效的策略参数。
如果第三条返回一堆validate_password.xxx变量，说明策略正在运行，那么你设简单密码必然撞墙；如果返回空结果，说明当前压根没有密码校验，报 1819 就得换个方向排查。我把这三条命令当作"病前三查"，无论帖子、文档里怎么说，先确认机器实际状态永远是第一步。
2. 默认策略的解剖：validate_password 的规则、等级和判定逻辑
2.1 三个等级，一条长度红线
validate_password的策略（policy）分三档，理解它比背参数重要得多：
| 等级 | 数值 | 强制条件 |
|---|---|---|
| LOW | 0 | 只检查密码长度 |
| MEDIUM | 1 | 长度 + 数字 + 大小写混合 + 特殊字符 |
| STRONG | 2 | MEDIUM 全部要求 + 字典文件检查 |
8.0 的默认策略是MEDIUM。也就是说，在默认情况下，一个密码要同时满足：长度不低于validate_password.length（默认 8）、包含至少 1 个数字、至少 1 个小写字母、至少 1 个大写字母、至少 1 个特殊字符。这几乎断了所有"省事密码"的活路。
我经常用一句话给刚接触的人概括：LOW 是只卡长度，MEDIUM 是五大门槛全要过，STRONG 还要防你把单词当密码。后面两档的规则还能通过参数调整，但这个等级结构是所有判断的基础。
2.2 参数一览与默认值
组件模式下的变量名都是validate_password.参数名这种带点号的格式，和 5.7 插件时代的validate_password_参数名下划线格式不一样，写配置文件的时候千万别混。常见的几个参数默认值如下：
| 变量名 | 默认值 | 含义 |
|---|---|---|
| validate_password.policy | MEDIUM | 策略等级 |
| validate_password.length | 8 | 密码最小长度 |
| validate_password.mixed_case_count | 1 | 至少包含的大小写字母数量（同时要求有小写和大写） |
| validate_password.number_count | 1 | 至少包含的数字数量 |
| validate_password.special_char_count | 1 | 至少包含的特殊字符数量 |
| validate_password.check_user_name | ON | 密码不能包含用户名 |
这里有个容易误会的点：mixed_case_count = 1不是"只要有一个字母即可"，而是必须同时存在至少一个大写字母和至少一个小写字母。5.7 时代这个参数叫validate_password_mixed_case_count，含义一样，但现在很多人翻老教程时对着新旧两种变量名来回试，搞到怀疑人生。
2.3 一个密码是怎么被"判死刑"的
拿MEDIUM默认参数举例子。假设你输入123456：
- 长度 6，低于默认长度 8，不通过；
- 只有数字，没有大小写字母，不通过；
- 没有特殊字符，不通过。
一条密码死在三个条件上，MySQL 却只回你一个 1819，毫无提示量。再看Abc#1234：
- 长度 8，达标；
- 包含数字
1、2、3、4，达标； - 包含小写
b、c和大写A，达标； - 包含特殊字符
#，达标。
所以它在默认策略下可以通过。整个判定过程是"一票否决制"，任何一个条件不满足就整体拒绝，不存在什么加权平均。知道这一点，你就能理解为什么网上那些"加个!就能过"的说法其实是碰巧凑齐了条件。
2.4 check_user_name 这个隐藏坑
很多人没注意到validate_password.check_user_name默认是ON，意思是密码不能包含当前的用户名。假设你是root用户，设root123这种密码，就算长度和复杂度全达标，也会因为包含了root直接报 1819。有一次我在一台测试机上眼睁睁看着一个同事对着密码调了半天，大小写加够了、特殊字符也有了，就是忘了密码里带了自己的用户名。
判断逻辑是按字符串包含关系比较的，不区分大小写，所以ROOT、Root、root都不行。要临时关掉可以执行SET GLOBAL validate_password.check_user_name = OFF，但我建议尽量别关，换个思路给用户起一个不容易写进密码的用户名，更省心。
2.5 字典检查的 STRONG 到底多烦
STRONG等级在MEDIUM的基础上还会检查字典文件，也就是validate_password.dictionary_file指向的单词列表。密码不能是字典里现成的单词，比如Password@123这种常见组合，如果字典文件里有password，照样会被拒绝。实际工作中用STRONG的场景很少，它主要出现在等保要求严格的政企环境里。日常开发完全用不上，但你要知道它存在，免得在某个客户环境里看到一个dictionary_file变量不知道是什么。
3. 本地开发环境改简单密码：从临时放行到永久放行的完整操作
3.1 动手之前先确认两件事
本地开发机、测试环境想用简单密码，这是完全合理的需求，没什么好羞耻的。但动手之前，先确认两件事：
第一，当前策略确实是validate_password在拦你，用前面说的三条命令查一遍；第二，想清楚你要的是"临时放行一次"还是"以后每次重启都放行"。这两个目标的操作路径完全不同，很多人就是没想清楚，改完当时能设密码了，重启之后又打回原形，然后开始怀疑人生。
我给的默认建议是：本地开发用"降级到 LOW + 放宽长度"方案，而不是彻底卸载组件。理由后面讲。
3.2 方案一：把策略降到 LOW（推荐）
假设你已经用临时密码登录，或者已经改好了一个强密码，目标是把 root 密码改成123456。按顺序执行：
SET GLOBAL validate_password.policy = LOW; SET GLOBAL validate_password.length = 6; FLUSH PRIVILEGES; ALTER USER 'root'@'localhost' IDENTIFIED BY '123456';这里有两个关键点，都是踩过的坑：
- 只降
policy = LOW还不够。LOW 仍然要检查length，默认值是 8，而123456只有 6 位，所以你只降策略不降长度，还是会被 1819 拦下来。我见过太多人卡在这一步，以为"LOW 就是啥都能设"。 SET GLOBAL是运行时设置，不写进配置文件的话，MySQL 服务一重启就恢复默认。如果你希望重启后策略依然宽松，需要在my.ini（Windows）或my.cnf（Linux）的[mysqld]段里追加：
[mysqld] validate_password.policy=LOW validate_password.length=6注意变量名要用点号格式。加了配置后重启服务，再用SHOW VARIABLES LIKE 'validate_password%'确认一下，别想当然。
3.3 方案二：彻底卸载 validate_password 组件
如果你追求"一了百了"，可以卸载组件：
UNINSTALL COMPONENT 'file://component_validate_password';执行完以后，validate_password系列变量全部消失，之前那套强度校验彻底下线，再执行ALTER USER ... IDENTIFIED BY '123456'就不会有任何阻拦。将来想恢复，执行：
INSTALL COMPONENT 'file://component_validate_password';组件卸载是持久化的，写入的是mysql.component系统表，不依赖服务重启状态。
为什么不把"卸载组件"作为首选方案？两个原因。第一，卸载是全局性的，你以后万一要在这个实例里建测试账号、模拟生产环境，密码策略全没了，容易养成坏习惯；第二，有些团队规范或后续排查工具会默认校验validate_password变量是否存在，组件没了反而多出一些解释成本。降级到 LOW 已经能设简单密码，没必要把整套机制拆掉。
3.4 放行之后的恢复动作
如果是临时放行，比如只是想改个密码然后继续用强策略，那么改完之后记得恢复：
SET GLOBAL validate_password.policy = MEDIUM; SET GLOBAL validate_password.length = 8;这个操作同样只影响当前运行实例，重启后如果my.ini里写的是LOW，那还是会以配置文件为准。所以要想清楚"恢复"到底恢复到哪里。也有人图省事，把my.ini里那两行策略参数永久写成LOW，然后只在应用层约束自己，这在纯本地的开发机上我能理解，但一旦这台机器暴露到内网甚至公网，风险就完全变了，下面专门聊生产环境。
4. 生产环境别照抄：策略松绑的最小代价与替代思路
4.1 为什么生产环境不要整体降级
本地开发怎么折腾都行，生产环境我只有一个态度：默认策略别动，尤其是别卸载 validate_password 组件。这不是教条，而是现实考虑。
首先，策略是全局的，MySQL 8.0 没有"只对某个账号放宽密码策略"的原生选项。你以为只是给一个老业务账号开了绿灯，实际上所有账号的密码门槛一起降了，包括 DBA 的 root、备份账号、监控账号。出现弱密码问题的时候，审计甩过来的清单上可不会只列那一个账号。
其次，生产环境的历史负担往往很重。今天你把策略降成 LOW，明天某个同事顺手建了个Admin123的业务账号，后天一台数据库被扫到弱口令，最后背锅的还是当初做这个决定的人。我在线上见过太多类似事故，几乎都是"临时为了图方便"开始，以"紧急整改"结束。
还有一个容易被忽略的点：如果你在生产环境装了validate_password然后又卸载，某些自动化巡检脚本会告警"缺少密码强度组件"，这会产生大量无效告警，把真正重要的告警淹没掉。
4.2 为老应用单账号开绿灯的折中方案
我知道现实里有不得不让步的时候，比如老应用写死了密码，改密码要动代码发版，而发版窗口排到下个月。这种场景下，我的折中方案是：
- 能不降级就不降级。先算算老应用用的密码能不能凑到 8 位 + 数字 + 大小写 + 特殊字符，很多时候目标密码只差一两个字符，完全可以在应用配置里同步调整。
- 必须降级时，守住底线。至少保持
policy = LOW且length = 12，只允许长度门槛，但把长度拉高。这样至少能拦住大量随手输入的弱口令扫描。 - 从网络层补漏。密码弱了，就用访问控制补：限制该账号只允许白名单 IP 连接、只授权业务库的最小权限、禁用远程 root 登录、开启插件日志留痕。弱密码 + 公网可达 + 全库权限，是生产事故的三大标配，任何一个都得堵上。
- 发版后第一时间恢复。把降低策略当作战时状态，记到变更单里，排期恢复，别让"临时"变成"永久"。我习惯在变更单里写明"2024-xx-xx 临时降低策略，预计恢复时间"，到期前一周提醒相关同事。
4.3 除了强度，还有密码过期和失败锁定
密码强度只是账号安全的一半，另外两件事经常被一起漏掉。
密码过期策略由default_password_lifetime控制，默认值是 0，表示密码永不过期。生产环境建议设置default_password_lifetime = 90，让账号定期改密；也可以针对单个账号单独设置：
ALTER USER 'app_user'@'%' PASSWORD EXPIRE INTERVAL 90 DAY;另一个是连续失败锁定，社区版里通常用connection_control插件实现。它可以在同一账号连续多次登录失败后，强制插入延迟甚至临时拒绝连接，能有效对抗暴力破解。安装和启用并不复杂，但很多人装机时根本不知道有这个东西。
4.4 认证插件是另一个容易被误伤的环节
和生产环境密码相关的还有一件事，不是策略本身，但经常和它一起爆发：8.0 默认的认证插件是caching_sha2_password，老版本的客户端、旧版 JDBC 驱动、某些老管理工具连不上，报错千奇百怪，最典型的是：
Authentication plugin 'caching_sha2_password' cannot be loaded一个常见操作是把账号改回老的mysql_native_password认证：
ALTER USER 'app_user'@'%' IDENTIFIED WITH mysql_native_password BY 'Some#Strong1';注意，这个命令里的密码同样要过validate_password的检查，所以 8.0 里很多"改了认证插件还是报 1819"的提问，本质是密码本身没过策略，不是认证插件的问题。另外mysql_native_password自 8.0.34 开始被官方标记为废弃，8.4 里默认禁用，所以新项目更推荐直接升级客户端和驱动，而不是回头用老插件。
5. 避坑实录：从临时密码到远程连接，那些连环坑
5.1 首次登录的临时密码和 expired 状态
8.0 安装完以后，root 账号会生成一个临时密码。Windows 上它可能出现在安装器界面，也可能在错误日志里。我用 ZIP 包手工安装时最常去这里找：
C:\ProgramData\MySQL\MySQL Server 8.0\Data\<主机名>.errLinux 上一般是：
grep "temporary password" /var/log/mysqld.log拿到临时密码登录后，账号处于密码过期（expired）状态。这个状态下你几乎只能执行改密码相关的语句，其他所有操作都会报ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement.很多人第一步直接执行SET GLOBAL validate_password.policy = LOW，想先放行再改密码，结果被 1820 弹回来，然后开始绕圈子。
正确顺序是：
- 先用临时密码登录；
- 立刻把它改成一个合规的强密码，比如
Temp#2024Abc； - 退出重新登录；
- 这时候再执行
SET GLOBAL validate_password.policy = LOW、SET GLOBAL validate_password.length = 6； - 最后再
ALTER USER 'root'@'localhost' IDENTIFIED BY '123456'。
流程确实是绕了一圈，但这是 MySQL 的机制所致，顺序反了就走不通。
5.2 组件卸载后装不回去？两个常见误操作
第一个误操作是重复安装。有些人先执行UNINSTALL COMPONENT，发现变量还在，于是又执行一次INSTALL COMPONENT，结果报"组件已存在"之类的错误。其实第一次UNINSTALL如果执行时提示成功，但SHOW VARIABLES还能查到变量，这通常是当前会话之前的缓存或者连接池里旧连接的状态，新开一个连接再查就干净了。别急着反复卸载安装，先断开会话确认。
第二个误操作更隐蔽：卸载组件后，my.ini里还留着validate_password.policy=LOW这样的配置。下次重启，服务加载配置时发现validate_password这个变量不存在，直接拒绝启动。Windows 上表现为服务启动失败、事件查看器里记录一条 unknown variable 错误。解决方法是把配置文件里的相关行删掉。所以我一直提醒：改配置要配套，卸载组件时记得清配置，安装组件时记得加配置。
5.3 Docker 里 MYSQL_ROOT_PASSWORD 设弱密码失败
用 Docker 跑 MySQL 8.0 的人越来越多，官方镜像通过环境变量MYSQL_ROOT_PASSWORD设置 root 密码。很多人在本地随手写：
environment: MYSQL_ROOT_PASSWORD: "123456"结果容器初始化失败，看日志发现同样是 1819。原因和裸装一模一样：官方镜像的初始化流程会启动一个临时 MySQL 实例来执行初始化 SQL，如果这个实例加载了validate_password，弱密码就会被拦。
我建议的几种处理方式：
- 如果只是本地联调，先用一个合规的初始化密码，容器起来之后再进容器执行降级策略并改成简单密码；
- 或者挂载一个配置文件到
/etc/mysql/conf.d/zz-policy.cnf，内容写[mysqld]下的validate_password.policy=LOW和validate_password.length=6，在首次初始化前就生效； - 再或者利用
/docker-entrypoint-initdb.d/目录挂载一个.sql脚本，在初始化阶段先执行SET GLOBAL再执行ALTER USER。
这里要特别留意：这些方法只对首次初始化空数据目录时有效。如果你的docker volume已经初始化过了，再改环境变量和配置文件都不会重建 root 密码，需要手动进容器改。
5.4 配置文件里写了策略参数，但服务起不来
这个坑在 Linux 上很典型。你用的是 5.7 时代的老教程，往my.cnf里写了：
validate_password_policy=LOW注意，这是下划线格式，对应的是旧插件变量。8.0 的组件变量是点号格式validate_password.policy。如果当前实例装的是组件而不是旧插件，下划线格式的变量名服务器不认，直接启动失败。反过来，如果你是按点号格式写的，但当前实例的组件没安装，同样也会因为 unknown variable 起不来。
所以每当你改完my.cnf服务起不来，第一反应应该是删掉刚加的行，而不是反复重启。等实例能正常启动了，再想清楚"变量格式对不对、组件装没装"这两个问题。
5.5 卸载重装后的策略残留
Windows 上卸载 MySQL 重装是高频操作，但很多人不知道mysql.component表存在数据目录里。你用控制面板卸载了安装器、删了C:\Program Files\MySQL\MySQL Server 8.0，但如果数据目录没清干净，重装时新实例可能会继承旧状态，包括已安装的组件、旧账号、旧密码策略。
更常见的是反过来：数据目录删了重建，组件回到出厂状态，配置文件却还在，结果新实例起不来，或者起来了但密码策略和你预期的不一样。我处理这种问题时的固定步骤是：先停服务、备份数据、彻底删除ProgramData下的数据目录、清空配置文件里的策略相关行、再重装。顺序不能乱，否则就是各种灵异现象。
6. 实操层面的个人建议
把这几年和validate_password反复纠缠的经验浓缩成几句话。
第一，本地开发机用 LOW + length=6 这个组合就够了，别直接卸载组件。保留组件意味着你随时可以切回 MEDIUM 模拟生产环境的行为，而不用重新装一遍。
第二，所有策略变更都要留痕。我在本地和测试机上都会在my.ini里写注释，标明这行是哪个需求、什么时候加的、什么时候可以删。看起来像是小题大做，但当你三个月后在一台陌生的机器上排查 1819 时，这段注释就是救命稻草。
第三，改完策略一定要验证。执行SHOW VARIABLES LIKE 'validate_password%'确认当前值，再开一个新会话测试登录，不要在一个会话里一条龙操作完就以为万事大吉。我在 Docker 里多次遇到"当时能登录、重建容器就废"的尴尬，就是吃了没验证的亏。
第四，密码策略只是入口，不是全部。就算本地开发密码设成123456，也记得关掉远程 root 登录、限制监听地址、随时准备销毁重建。开发机最大的价值就是可以随时推倒重来，既然密码已经弱了，其他防护就尽量别省。
最后分享一个很实用的检查思路：每次碰到 1819，先问自己三个问题——当前实例到底有没有装validate_password？当前策略是哪个等级？我改的是运行时变量还是配置文件？三个问题查一遍，90% 的密码坑都能原地解决，剩下的 10% 基本就是 Docker 数据目录或重装残留这些场景，照着上面第五节的内容也能定位。
