你大概率是在这里碰到它的MySQL 装好了临时密码也看到了正打算给 root 换一个新密码结果终端甩回来一行鲜红的ERROR 1819 (HY000): Your password does not satisfy the current policy requirements。如果你正在硬着头皮搜“mysql ERROR 1819 怎么解决”那恭喜你问题一点也不罕见这是 MySQL 密码策略组件在挡路。这个报错的本质很简单你设置的密码太弱没通过validate_password的校验。MySQL 默认的密码策略需要密码同时满足长度、大小写、数字、特殊字符等要求所以你随手写的123456或者root是进不去的。这篇东西主要就是讲清楚这个策略到底怎么工作、怎么快速设一个合规密码、怎么在开发环境把策略调低甚至关掉以及不同安装方式Linux、Docker、Windows 本机下你会踩到的具体坑。适合刚装完 MySQL 的初学者也适合被这问题搞烦了的运维和开发。1. 报错是怎么触发的密码策略在把关1.1 validate_password 不是故意刁难你MySQL 从 5.7 开始引入了密码校验机制用来防止用户设置过于简单的密码。它由validate_password这个模块实现在 5.7 里它叫“插件”plugin在 8.0 里升级成了“组件”component。虽然叫法不同干的事一样——它会在你执行CREATE USER、ALTER USER、SET PASSWORD这些涉及密码变更的命令时对新密码做一轮完整检查不合格的直接拒绝并抛出ERROR 1819 (HY000)。我在实际环境里见过不少同事第一反应是“MySQL 出 bug 了”其实不是。它就是一个安全闸门类似机场安检行李密码不达标就不让过人家不解释你缺的是打火机还是超重只给你一句话“does not satisfy the current policy requirements”。你唯一能做的就是要么换个合规行李要么把安检标准调低。这里有个容易忽略的细节这个模块在部分默认安装下是开启的。尤其是 Linux 上用 RPM、APT 方式安装的 MySQL 8.0初始化完成后validate_password往往是激活状态所以你第一次改 root 密码就撞上了。如果你是用某些官方二进制包或者其他自定义方式装的可能没启用那你就不会遇到这个问题。这也是为什么网上有人喊“我同样操作没事”因为大家的安装形态不同。1.2 三种策略等级默认要求到底有多高validate_password提供三档策略等级对应的参数在 8.0 里叫validate_password.policy在 5.7 里叫validate_password_policy。默认等级是1也就是MEDIUM。策略等级校验内容MySQL 8.0 默认参数LOW0只检查密码长度validate_password.length8MEDIUM1长度 大写字母 小写字母 数字 特殊字符length8、mixed_case_count1、number_count1、special_char_count1STRONG2MEDIUM 全部要求 密码不能匹配字典文件在 MEDIUM 基础上还需要配置dictionary_file默认的 MEDIUM 意味着你要设的密码必须同时满足至少 8 位、至少 1 个大写字母、至少 1 个小写字母、至少 1 个数字、至少 1 个特殊字符。所以123456、root、admin、password这类密码全部秒拒。很多人不理解为什么自己明明设了 8 位还是报错——因为只满足长度一项后面的字母和字符要求没跟上。看一下当前实例的校验规则很简单登录 MySQL 后执行SHOW VARIABLES LIKE validate_password%;8.0 的显示基本是下面这样validate_password.check_user_name ON validate_password.dictionary_file validate_password.length 8 validate_password.mixed_case_count 1 validate_password.number_count 1 validate_password.policy MEDIUM validate_password.special_char_count 1看到policyMEDIUM那一刻你就知道为什么 1819 拦你了。如果policy列为空说明当前实例根本没启用密码策略那出现 1819 的概率极低。先做这一步能少走很多弯路。2. 最快的解决办法按策略规则改密码2.1 构造合规密码的公式如果你不想动配置只想立刻把密码改成功那最简单的办法就是制造一个满足 MEDIUM 策略的密码。给个通用公式大写字母 小写字母 数字 特殊字符拼一起保证总长度 8 位以上。比如这样几个都可以Mysql2024 Root_1234! Test#Pass9然后执行ALTER USER rootlocalhost IDENTIFIED BY Mysql2024;顺利的话MySQL 会返回Query OK这个报错就过去了。核心就两件事看清楚你的策略要哪些元素缺哪个补哪个。这里我多提一句容易被忽略的问题改完密码后记得顺手验证一下是否能正常登录别急着关终端。用mysql -uroot -p重新登一次输入新密码确认可以进再把旧的临时密码从脑袋里删掉。很多人在改密码这条命令执行成功后以为完事了结果过了一会儿发现 Navicat 连不上——那是另一个问题比如认证插件不兼容我在第 5 章会单独说。2.2 临时密码复制到终端时的坑很多用 Linux 安装包方式装 MySQL 的朋友第一步是去/var/log/mysqld.log里找临时密码。找是找到了复制到终端里却怎么都登录不进去。常见原因是你把整行文本都复制了进去临时密码前后带着空格或者日志前缀shell 把多余内容也当成密码的一部分了。我的建议是用鼠标选中临时密码那一串字符时只复制冒号后面的连续字符不要带前后空格如果实在复制不干净先粘贴到记事本里检查一遍再执行。另一种情况是临时密码里有特殊字符个别字符在 bash 里会被解释比如$、!、?这时可以给密码加单引号来消除 shell 的干扰mysql -uroot -p你的临时密码不过在命令行直接带密码本身也有安全隐患进程列表里会明文暴露。更稳妥的做法是只敲mysql -uroot -p然后等提示符出现再手动输入密码。3. 想放松限制从调参数到完全关闭的完整方案3.1 临时把策略调到 LOW对于开发环境、测试环境让每个同事都去背 8 位含特殊字符的密码确实有点痛苦。这也是我日常工作里的常规操作直接把策略降到 LOW同时把最小长度降一降。SQL 这么写MySQL 8.0 版本SET GLOBAL validate_password.policy LOW; SET GLOBAL validate_password.length 6;5.7 版本写法略有差异参数名是下划线形式SET GLOBAL validate_password_policy 0; SET GLOBAL validate_password_length 6;执行完再看一眼变量SHOW VARIABLES LIKE validate_password%;你会发现policy变成了LOWlength变成了6。这个时候你随手设一个abc123都能通过。这里要注意SET GLOBAL只对当前运行中的实例生效不会写进配置文件MySQL 服务重启后就会恢复默认值。如果你只想“临时救急”这种方式最合适如果你想永久生效还得改配置文件。3.2 将参数写入配置文件永久生效要永久把密码策略放松就得把参数写进 MySQL 配置文件。不同系统和安装方式配置文件路径不太一样常见的是下面几个Linux RPM 方式/etc/my.cnf或者/etc/my.cnf.d/下的某个.cnf文件Windows安装目录下的my.iniDocker通过挂载自定义配置比如/etc/my.cnf在[mysqld]段下加两行8.0 用点号写法[mysqld] validate_password.policy LOW validate_password.length 65.7 则写[mysqld] validate_password_policy 0 validate_password_length 6保存后重启 MySQLsystemctl restart mysqld重启完务必再执行一次SHOW VARIABLES LIKE validate_password%;确认参数真的生效了。我见过不少人改完配置文件后忘了重启或者把参数写进了错误的.cnf文件导致看上去改了但实际没生效白白排查半天。3.3 直接卸载组件彻底关闭密码检查如果你是在本地开发环境实在不想被密码策略烦也可以直接把validate_password整个卸掉。8.0 里它是组件卸载语句是UNINSTALL COMPONENT file://component_validate_password;5.7 里是插件卸载语句是UNINSTALL PLUGIN validate_password;执行完之后再查SHOW VARIABLES LIKE validate_password%;应该是空结果代表密码策略已经不存在了。之后你设任何密码都不会再触发 1819。但这里我要把话说重一点生产环境强烈不建议这么做。密码策略是数据库的第一道防线root 或被提权的账号一旦被爆破数据就真的交给别人了。我在实际项目里给生产库设密码都是乖乖用 MEDIUM 以上策略密码写到公司密码管理器里。开发/测试环境随便折腾可以生产还是老实一点。4. 不同环境下的实操记录4.1 场景一Linux 上 RPM 安装 MySQL 8.0 后改 root 密码这是遇到 1819 最典型的一个场景。我的完整操作流程大概是这样。先看初始化的临时密码grep temporary password /var/log/mysqld.log登录mysql -uroot -p执行改密ALTER USER rootlocalhost IDENTIFIED BY Mysql2024;如果临时密码本身是带特殊字符的用单引号把它包起来再登录避免 bash 解释。这条命令执行完root 密码就是Mysql2024了后面再用这个密码登录即可。有些人在第 4 步仍然报 1819那说明你构造的密码其实还没完全满足策略。比如你设的是Mysql2024看起来有大小写、有数字但缺个特殊字符照样被拒。这种情况下就执行SHOW VARIABLES LIKE validate_password%;一项一项对着参数检查差异缺符号补符号缺长度补长度。4.2 场景二Docker 容器初始化失败和容器内调策略用 Docker 跑 MySQL1819 出现的姿势往往更隐蔽。很多人执行这样一条命令docker run -d --name mysql-test -e MYSQL_ROOT_PASSWORD123456 -p 3306:3306 mysql:8.0结果容器启动没几秒就退出了看日志docker logs mysql-test里面对应的报错就是ERROR 1819 (HY000): Your password does not satisfy the current policy requirements原因很简单容器官方镜像的初始化脚本会用MYSQL_ROOT_PASSWORD这个环境变量里的值去设置 root 密码而这个设置动作同样会经过validate_password校验。123456这种弱密码在 8.0 容器镜像下根本过不了关。最简单的解决方案是把环境变量里的密码设为合规密码docker run -d --name mysql-test -e MYSQL_ROOT_PASSWORDMysql2024 -p 3306:3306 mysql:8.0如果你在已有的容器里想去改密码策略可以这样进入容器docker exec -it mysql-test mysql -uroot -p进去之后同样执行SET GLOBAL validate_password.policy LOW; SET GLOBAL validate_password.length 6;但这些设置不会写进容器镜像容器一旦删除重建策略又会恢复默认。所以你要对容器长期配置做修改应该用挂载配置文件的方式在宿主机上做好/etc/my.cnf然后通过-v挂载进去docker run -d --name mysql-test -v /path/to/my.cnf:/etc/my.cnf -e MYSQL_ROOT_PASSWORDMysql2024 -p 3306:3306 mysql:8.0这样策略调整才是可持续的。4.3 场景三Windows 本机和 Ubuntu 的变体问题Windows 上装 MySQL 8.0配置文件一般在安装目录下比如C:\ProgramData\MySQL\MySQL Server 8.0\my.ini。遇到 1819在[mysqld]段下加配置然后以管理员身份重启 MySQL 服务即可。注意 Windows 下参数名同样遵循 8.0 的点号写法别把 5.7 的写法搬过来。Ubuntu 下用apt安装 MySQL 的朋友要注意另一个情况默认 root 用户走的是auth_socket认证也就是你在系统里用sudo mysql可以免密进数据库但普通 TCP 连接和密码登录是不行的。如果你尝试给 root 设置密码但策略不满足同样报 1819。即使你把密码改成合规格的后续用 Navicat 等工具连接时可能还会遇到访问被拒的问题因为认证插件不匹配。这个我在第 5 章会给出对应解法。5. 常见问题排查与避坑指南5.1 常见报错变体速查表报错信息常见原因处理建议ERROR 1819 (HY000) policy requirements新密码不满足 validate_password 策略看validate_password*参数构造合规密码或调低策略ERROR 1045 (28000) Access denied密码错误或认证方式不匹配如 auth_socket、caching_sha2_password确认真实密码确认用户允许从当前 Host 登录必要时切换认证方式ERROR 1396 (HY000) Operation ALTER USER failed指定用户不存在或 Host 不匹配确认用户全名比如rootlocalhost和root%是不同用户ERROR 1251 (08004) Client does not support authentication protocolMySQL 8.0 默认认证插件caching_sha2_password旧客户端不支持升级客户端或把用户认证方式改为mysql_native_password容器启动失败日志有 1819镜像初始化设置密码时被策略拦截设置合规密码作为MYSQL_ROOT_PASSWORD或调整容器内密码策略这个表是从我日常接手的各种场景里总结出来的。很多人的实际问题并不是 1819而是在处理 1819 的过程中又碰到了 1045、1251尤其是拿 Navicat 去连的时候。我建议把 1819 本身和认证方式问题分开排查密码策略只负责“能不能改”认证插件负责“能不能连”。两个环节都通了整个流程才顺畅。5.2 改了配置却不生效八成是这几个原因最让人上火的情况是配置文件明明改了重启也重启了密码策略还是原来的老样子。我整理几个概率最高的坑。第一个是参数名写错版本。5.7 用下划线、8.0 用点号这两个混用的症状不是“报错”而是 MySQL 直接忽略识别不了的参数。你查变量时发现还是默认值但日志里一般没有明显错误。这种时候要养成改完配置后跑SHOW VARIABLES LIKE validate_password%;确认的习惯。第二个是重启方式不对。我曾经见过有人在容器里执行systemctl restart mysqld结果提示找不到服务然后他说“配置文件里改了没用”。实际上容器里要的是docker restart容器名或者进入容器用服务管理命令重启。你用错了重启工具配置自然没加载。第三个是改错了配置文件。Linux 上 MySQL 可能同时存在/etc/my.cnf和/etc/my.cnf.d/下的多个文件有的发行版会加载/etc/mysql/目录。你在某个.cnf文件里改了但 MySQL 读的是另一个文件。可以执行mysqld --verbose --help | grep my.cnf来看当前实例到底读了哪些配置文件或者直接看/etc/my.cnf主文件里的includedir配置。5.3 密码里的特殊字符在 shell 中的坑这条是给经常在命令行直接执行 SQL 的读者准备的。假设你设的密码是Mysql2024!然后在 bash 里直接跑mysql -uroot -p -e ALTER USER rootlocalhost IDENTIFIED BY Mysql2024!;有时会出奇怪的问题因为!在双引号里可能触发 shell 的历史扩展把命令搞乱。更麻烦的是密码本身含有单引号比如Mysql2024那 SQL 里的字符串包裹方式就会和你打架。我的习惯是密码尽量不用!、$、、\这类在 shell 或 SQL 里有特殊含义的字符实在要用就避开命令行直接执行 SQL进入 MySQL 交互环境后执行ALTER USER。另外不要把密码直接写在-p后面用交互输入的方式最安全也避免密码出现在 shell 历史记录里。还有一点要提醒不要在 SQL 里通过远程工具把含中文或空格的特殊密码填入部分客户端的字符集处理会有编码差异可能导致密码写入和读取不一致。密码里用可见的 ASCII 可打印字符最省心。6. 我在实际环境里留下的几点笔记最后分享几个我自己的习惯未必适用所有人但都是实打实踩过坑换来的。首先开发环境的密码策略我一般只降到LOW而不是把组件整个卸载。因为卸载确实一劳永逸但万一哪天某个同事要在这个实例上做测试或者要复用同一套环境模拟生产没有策略约束反而容易写出特别弱的密码安全隐患被忽视了。降到 LOW 还能保留长度检查这个底线算是个折中。其次遇到 1819 第一步一定是执行SHOW VARIABLES LIKE validate_password%;先看策略再动手。很多时候你不是不会改密码而是不知道策略要求什么。把变量列表拉出来对照检查十秒能定位到问题。还有就是容器场景我遇到过不止一次同事跑 MySQL 镜像启动失败日志里翻出来是 1819但他们第一反应都是“镜像是不是坏了”。其实镜像没坏就是环境变量里那个密码太简单了。碰到容器启动失败先别急着删镜像把容器日志拉出来看一眼报错信息往往直接把答案写在脸上。如果你看完这篇还卡在同一类 1819 问题上大概率是版本差异导致的参数写法问题。把 MySQL 版本确认一下SELECT VERSION();再回来对照本文的 5.7、8.0 写法思路马上就能理清。