MySQL改密码这活儿看起来简单实际上翻车率极高。尤其是那些动不动就清空重装、用UPDATE mysql.user SET password...硬改的老方法到了 MySQL 5.7 之后基本就是给自己挖坑。我平时处理得最多的现场问题不是“密码忘了怎么办”而是“密码改了一半MySQL 起不来了”“改了密码重启之后又变回去了”“明明照着网上文章操作怎么报语法错误”。这些事十有八九都绕不开同一个因素——配置文件。所以这篇我把“改密码”和“配置文件”放在一起讲不是没道理的MySQL 的密码机制、认证插件、密码策略、以及忘记密码时的救援路径全部由配置文件和系统表共同决定。搞懂这两者的关系比背一百条命令都管用。1. 为什么改密码这件事绕不开配置文件先捋个底层逻辑MySQL 的用户密码信息其实是一张系统表里的记录准确说是mysql.user表。你执行任何“改密码”的命令本质上都是在修改这张表里的authentication_string字段以及关联的认证插件plugin字段。但问题在于MySQL 服务器进程本身是一套独立运行的程序它认不认你这条修改命令、允不允许你改、用什么规则校验新密码全取决于它启动时的运行状态和机制配置——这些状态和机制又基本由启动时的配置文件决定。打个比方MySQL 服务器像一个安保严格的大楼。修改密码的命令是你到大楼前台去登记换门禁卡而配置文件就是大楼的管理制度什么时候开门、什么人能进、门禁卡用什么加密格式、密码要几位数。制度不改你光在那儿喊“我要换卡”是没用的或者换了也进不了门。这就是为什么你会看到下面这些现象密码改完了但 MySQL 8.0 的老客户端连不上十有八九是认证插件不兼容而默认认证插件由default_authentication_plugin决定密码设置得太简单直接被validate_password组件拦下来这东西也是通过配置文件初始化的忘记密码时大家最常用skip-grant-tables绕过认证这本身就是修改配置文件再重启服务更稳妥的init-file重置方案同样需要往配置文件里挂参数。结论改密码并不只是执行一条 SQL而是“配置文件 → 服务器启动状态 → 身份认证机制 → 授权表更新”这条链路里的一个环节。所以后面所有的操作我都会把配置文件的变化一起讲清楚否则你照着别人的命令敲完换到自己的环境必然出事。2. 正常路径改密码四种常用方式与版本差异如果用户还记得当前密码或者你有足够的管理员权限能登录进去那改密码就是纯粹的 SQL 操作。但即便这步简单版本差异也能坑人先说清楚。2.1 ALTER USERMySQL 5.7 以后的首选MySQL 5.7.6 以后官方把ALTER USER当作修改密码的推荐写法ALTER USER rootlocalhost IDENTIFIED BY NewPass123!;执行完不需要额外FLUSH PRIVILEGES因为这条语句直接更新系统表并同步权限缓存。如果你嫌默认的认证插件不好或者想兼容某些老客户端可以显式指定插件ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY NewPass123!;WITH mysql_native_password的意思是让该用户继续用老式的 MySQL 原生密码插件而不是 MySQL 8.0 默认的caching_sha2_password。这个后面聊默认插件时细说。2.2 SET PASSWORD老牌写法的变迁在 MySQL 5.6 及更早的时代大家最熟悉的写法长这样SET PASSWORD FOR rootlocalhost PASSWORD(newpass);注意PASSWORD()函数在 MySQL 5.7 中被标记为废弃MySQL 8.0 直接移除。今天你在 8.0 里敲这行会见到ERROR 1305之类的报错。新版写法不再需要函数包裹SET PASSWORD FOR rootlocalhost NewPass123!;如果是给自己改当前登录用户也可以简化成SET PASSWORD NewPass123!;2.3 mysqladmin命令行快速改不想进 SQL 交互界面可以直接用mysqladminmysqladmin -u root -pOldPass123 password NewPass123!老密码在-p后面跟着新密码写在最后一个参数。这种方式适合脚本自动化但注意命令行里明文带密码shell 历史记录会留下痕迹生产服务器慎重。2.4 手改 mysql.user 表的坚持派网上大量老文章教你这样USE mysql; UPDATE user SET PasswordPASSWORD(newpass) WHERE Userroot; FLUSH PRIVILEGES;这条链路的隐患在于MySQL 5.7 之后mysql.user表里并不存在可直接填写的Password列实际字段叫authentication_string你 UPDATE 完还要正确地同步插件稍有差错就会变成“密码显示是改了但怎么都登不上”。我早些年吃过这个亏因为照着一篇老文章在 5.7 环境里更新了authentication_string但忘了处理plugin字段结果 root 账户的认证插件和哈希格式不匹配最后只能走重置流程。现在我的立场很明确非紧急救援场景不要直接改表。系统表的结构每个大版本都可能变SQL语句等价性也不如官方封装好的命令可靠。2.5 顺手查看修改结果改完别急着走先确认系统表里到底存了什么SELECT user, host, plugin, authentication_string FROM mysql.user WHERE userroot;在 MySQL 8.0 中plugin字段通常是caching_sha2_passwordauthentication_string是一长串哈希值。确认这两项都对心里才有底。3. 忘记密码的紧急通道skip-grant-tables 与 init-file忘记 root 密码是 DBA 和运维的日常噩梦。此时没有合法登录方式只能靠服务器启动阶段的握手漏洞来做“救援”。配置文件在这里就是完全的主角。3.1 方案一skip-grant-tables 传统救法这个思路很简单让 MySQL 启动时跳过权限验证也就是不加载授权表。做法如下。第一步停掉 MySQL 服务。Linux 上多半是sudo systemctl stop mysqld # 或 sudo /etc/init.d/mysql stop第二步编辑配置文件一般位于/etc/my.cnf或/etc/mysql/my.cnfWindows 下是安装目录里的my.ini在[mysqld]段落下加两行[mysqld] skip-grant-tables skip-networkingskip-networking不是必须但强烈建议加它让 MySQL 只听本机 socket防止绕过认证后开放 TCP 端口被外部扫到。救援期间把自己锁在本机里是基本的安全觉悟。第三步启动服务sudo systemctl start mysqld然后直接免密登录mysql -u root注意此刻你不需要密码因为它根本没查授权表。第四步先刷权限再改密码FLUSH PRIVILEGES; ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY NewPass123!;这里有两个细节值得讲刚进skip-grant-tables模式时权限系统是“不加载”的直接执行ALTER USER经常报“无法修改”或干脆提示相关权限不足。先FLUSH PRIVILEGES把授权表重新加载一遍当前会话才有足够权限改系统表。如果你不指定WITH mysql_native_password执行可能会把 root 的插件重置成默认值某些老客户端会连不上。为了减少变量我习惯在这个场合显式指定原生密码插件完成后再根据业务需要调整。第五步必须要做的收尾删掉配置里的skip-grant-tables和skip-networking重启 MySQL然后正常登录验证mysql -u root -p这里有个非常容易犯的错误改完密码后忘记把skip-grant-tables注释掉直接重启。结果是 MySQL 依然处于跳过认证状态任何用户不需要密码就能登进库相当于把大门拆了。安全审计真要查起来属于重大事故。3.2 方案二init-file 官方推荐的“干净”重置MySQL 官方文档更愿意推荐用init-file方案因为它不需要进入无认证的裸奔状态。原理是mysqld 启动时会按顺序执行init-file指定的 SQL 文件。第一步创建一个文本文件比如放在安全目录sudo vi /var/lib/mysql-files/reset.sql文件内容写ALTER USER rootlocalhost IDENTIFIED BY NewPass123!;如果 MySQL 8.0 中该用户当前的插件需要显式指定也可以写ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY NewPass123!;第二步改配置文件在[mysqld]段加一行[mysqld] init-file/var/lib/mysql-files/reset.sql第三步重启 MySQLsudo systemctl restart mysqldmysqld 在初始化阶段读到这个文件并执行里面的 SQL密码就直接改掉了。启动完成后立刻删除或注释配置里的init-file并删除或清理该 SQL 文件然后再次重启确认mysql -u root -p3.3 两种救援方案的对比维度skip-grant-tablesinit-file原理跳过授权表加载免认证登录启动阶段预执行 SQL 重置密码风险期间无认证容易裸奔较低正常认证流程仍在操作步骤较多要 flush 后再改简单启动即完成对服务的占用需要长期处于停止状态再改只需一次滚动重启适合场景系统已进不去命令极端紧急具备文件操作权限时的常规救援我在真实运维里能走init-file就不走skip-grant-tables。原因很简单前者不需要在“没有认证”的窗口期做太多操作出错概率小得多。4. 配置文件中直接决定密码体验的几个隐藏开关如果说上面是“改密码时怎么用配置文件”那这里就是“配置文件里哪些参数平时就在影响你的密码”。搞懂这些很多看似莫名奇妙的报错会豁然开朗。4.1 默认认证插件default_authentication_pluginMySQL 8.0 开始默认认证插件从mysql_native_password换成了caching_sha2_password。这是为了更强的安全性但也带来一个非常现实的问题老版本客户端、老语言驱动可能不支持新插件导致“密码明明对就是连不上”。你可以在配置文件中强制指定默认插件[mysqld] default-authentication-pluginmysql_native_password或者反过来保持默认但在创建用户时明确指定插件。这玩意儿属于“全局开关”改动前一定要先确认客户端、驱动、中间件的兼容性别为了某台老机器把整个库的默认策略都改掉。4.2 密码策略组件validate_password 系列如果你执行ALTER USER设置123456这种密码得到的报错经常是ERROR 1819 (HY000): Your password does not satisfy the current policy requirements这就是validate_password组件在拦。它同样可以由配置文件控制初始策略。比较老的 MySQL 5.7 时期配置项风格如下[mysqld] plugin-loadvalidate_password.so validate_password_policyMEDIUM validate_password_length8MySQL 8.0 装组件之后系统变量改成了点分隔常见的有[mysqld] validate_password.policyMEDIUM validate_password.length8 validate_password.mixed_case_count1 validate_password.number_count1 validate_password.special_char_count1策略等级一般三档LOW只校验长度MEDIUM长度 数字 大小写/特殊字符组合STRONG在上面基础上还要查字典文件拒绝常见弱密码。日常开发环境、测试库我建议用LOW或MEDIUM就够了生产环境再上STRONG。不然你给业务方开账号时对方随便设个密码就报错运维群里全是你的消息。4.3 救援模式开关skip-grant-tables 的注意事项这个参数严格来说不算“密码策略”但它直接影响密码修改能否成功、能否反复使用。尤其要注意加了它之后很多 SQL 行为会和正常模式不同。最典型的表现是在skip-grant-tables模式下如果你不先FLUSH PRIVILEGES某些版本的 MySQL 会拒绝执行权限相关操作甚至会提示当前用户没有权限。因为授权表没加载服务器不知道该不该信任你。这个坑我亲眼见过不少人踩——明明已经免密登进去了敲ALTER USER却被权限拒绝一时想不通。4.4 客户端侧的配置文件~/.my.cnf改完密码后你可能有多个终端或定时任务在用这套账号。服务器上经常有~/.my.cnf里存了旧的账号密码不更新的话定时任务会在午夜悄悄失败。常见结构[client] userroot passwordNewPass123!注意这里的password是明文权限最好设为仅当前用户可读chmod 600 ~/.my.cnf这是把“双刃剑”用好的关键日常命令行可以免输密码但保护不当就等于把数据库大门钥匙贴门框上。4.5 一张示例配置文件全景把以上参数拼在一起一个典型的、包含密码相关配置的片段长这样[mysqld] datadir/var/lib/mysql socket/var/lib/mysql/mysql.sock # 默认认证插件 # default-authentication-pluginmysql_native_password # 密码策略MySQL 8.0 组件式变量 # validate_password.policyMEDIUM # validate_password.length8 # 忘记密码时的救援开关用完务必注释 # skip-grant-tables # skip-networking # 启动时执行的 SQL 文件用完删除 # init-file/var/lib/mysql-files/reset.sql [client] # 本地命令行免密登录配置按需启用 # userroot # passwordYourPass123!5. 改完不生效排查链路和验证技巧退一万步讲这些命令你都照做了但 MySQL 依然不买账那多半问题出在下面几个容易被忽略的环节。我按实际排查顺序捋一遍。5.1 配置文件究竟被读到了没有很多人改了my.cnf重启后一脸茫然“我为啥没生效” 多半是文件路径不对。Linux 下配置文件有读取顺序的你可以用下面的命令看服务器实际读了哪些mysqld --verbose --help | grep -A 1 Default options输出大致是这样Default options are read from the following files in the given order: /etc/my.cnf /etc/mysql/my.cnf /usr/local/mysql/etc/my.cnf ~/.my.cnf如果在/etc/my.cnf和/etc/mysql/my.cnf里各写了一套配置先被读取的文件的同名参数会有优先权后者可能被覆盖。排查时先确认你改的文件在不在列表里以及有没有被其它文件盖掉。Windows 下更难受my.ini可能不在安装目录而是藏在数据目录或服务启动参数里。建议直接看服务启动命令行sc qc mysql或者看进程参数wmic process where namemysqld.exe get commandline5.2 修改配置后重启失败改完配置一systemctl restart mysqld服务直接起不来或者无限重启。常见原因init-file指向的 SQL 文件权限不对mysqld 用户读不了SQL 文件内容有语法错误启动阶段执行失败配置里同时开了skip-grant-tables和init-file两套逻辑互相干扰。排查时直接看错误日志通常位于/var/log/mysql/error.log或者/var/log/mysqld.logtail -100 /var/log/mysqld.log日志里会告诉你具体是哪个文件、哪段配置没被识别。我遇到过最离谱的一次是配置文件末尾多了个不可见字符mysqld 把参数值截断了折腾了半小时才定位到。5.3 新密码被密码策略卡住前面说过validate_password组件会拦弱密码。你可以在当前会话里先查看策略要求到底是什么SHOW VARIABLES LIKE validate_password%;根据自己的业务需要要么设置一个符合要求的复杂密码要么在确认环境允许的前提下暂时调低策略SET GLOBAL validate_password.policyLOW; SET GLOBAL validate_password.length6;注意SET GLOBAL只在当前运行期生效重启后还是会回到配置文件里的初始值。要永久调整改配置文件里那一段再重启。5.4 客户端连接报错却排除密码本身如果密码改成功但连接工具依旧报错优先怀疑认证插件是否匹配。判断方式如下先用命令行确认当前用户插件SELECT user, host, plugin FROM mysql.user WHERE user你的用户;如果插件是caching_sha2_password而你的老客户端驱动只支持mysql_native_password那就老老实实给这个用户单独指定插件ALTER USER 你的用户host IDENTIFIED WITH mysql_native_password BY 你的新密码;在 MySQL 5.7 时代基本不存在这个烦恼MySQL 8.0 后这是重灾区。尤其是一些用老版本mysql-connector-java、PHP mysqlnd连接的生产系统环境不升级库是 8.0改密码后就等着挨骂吧。5.5 改完以后验证的完整套路我不管给谁处理数据库改完密码都会走一遍完整的验证链路缺一不可第一步本机 socket 登录mysql -u root -p第二步确认当前会话确实是目标账号SELECT CURRENT_USER();第三步检查插件和认证字符串SELECT user, host, plugin, authentication_string FROM mysql.user WHERE userroot;第四步从远程主机用 TCP 协议做一次连接测试确认走了网络栈而不是本地 socket 的特殊权限mysql -h 192.168.x.x -P 3306 -u root -p如果远程连不上但本地没问题你再去看bind-address、防火墙、以及mysql.user表里是否真的存在root%或对应主机条目。很多人在这一步发现的根本不是密码问题而是账户 host 匹配问题。最后多说一句我在实际处理中最大的体会是改密码这件事改之前一定先看版本改之后一定先看配置改完重启前一定再想三秒有没有删掉救援开关。MySQL 5.7 和 8.0 的语法变化、插件机制、系统表结构差异都能让旧文章失效而配置文件是这些差异的集中体现。把“命令 配置 版本”这三件事串成一条线你就能从“照着抄”变成“真正懂”。 
长河君 · 2026/10/21 17:27:52 · 阅读 1.2k MySQL改密码总翻车？配置文件与认证插件是关键
MySQL改密码这活儿看起来简单实际上翻车率极高。尤其是那些动不动就清空重装、用UPDATE mysql.user SET password...硬改的老方法到了 MySQL 5.7 之后基本就是给自己挖坑。我平时处理得最多的现场问题不是“密码忘了怎么办”而是“密码改了一半MySQL 起不来了”“改了密码重启之后又变回去了”“明明照着网上文章操作怎么报语法错误”。这些事十有八九都绕不开同一个因素——配置文件。所以这篇我把“改密码”和“配置文件”放在一起讲不是没道理的MySQL 的密码机制、认证插件、密码策略、以及忘记密码时的救援路径全部由配置文件和系统表共同决定。搞懂这两者的关系比背一百条命令都管用。1. 为什么改密码这件事绕不开配置文件先捋个底层逻辑MySQL 的用户密码信息其实是一张系统表里的记录准确说是mysql.user表。你执行任何“改密码”的命令本质上都是在修改这张表里的authentication_string字段以及关联的认证插件plugin字段。但问题在于MySQL 服务器进程本身是一套独立运行的程序它认不认你这条修改命令、允不允许你改、用什么规则校验新密码全取决于它启动时的运行状态和机制配置——这些状态和机制又基本由启动时的配置文件决定。打个比方MySQL 服务器像一个安保严格的大楼。修改密码的命令是你到大楼前台去登记换门禁卡而配置文件就是大楼的管理制度什么时候开门、什么人能进、门禁卡用什么加密格式、密码要几位数。制度不改你光在那儿喊“我要换卡”是没用的或者换了也进不了门。这就是为什么你会看到下面这些现象密码改完了但 MySQL 8.0 的老客户端连不上十有八九是认证插件不兼容而默认认证插件由default_authentication_plugin决定密码设置得太简单直接被validate_password组件拦下来这东西也是通过配置文件初始化的忘记密码时大家最常用skip-grant-tables绕过认证这本身就是修改配置文件再重启服务更稳妥的init-file重置方案同样需要往配置文件里挂参数。结论改密码并不只是执行一条 SQL而是“配置文件 → 服务器启动状态 → 身份认证机制 → 授权表更新”这条链路里的一个环节。所以后面所有的操作我都会把配置文件的变化一起讲清楚否则你照着别人的命令敲完换到自己的环境必然出事。2. 正常路径改密码四种常用方式与版本差异如果用户还记得当前密码或者你有足够的管理员权限能登录进去那改密码就是纯粹的 SQL 操作。但即便这步简单版本差异也能坑人先说清楚。2.1 ALTER USERMySQL 5.7 以后的首选MySQL 5.7.6 以后官方把ALTER USER当作修改密码的推荐写法ALTER USER rootlocalhost IDENTIFIED BY NewPass123!;执行完不需要额外FLUSH PRIVILEGES因为这条语句直接更新系统表并同步权限缓存。如果你嫌默认的认证插件不好或者想兼容某些老客户端可以显式指定插件ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY NewPass123!;WITH mysql_native_password的意思是让该用户继续用老式的 MySQL 原生密码插件而不是 MySQL 8.0 默认的caching_sha2_password。这个后面聊默认插件时细说。2.2 SET PASSWORD老牌写法的变迁在 MySQL 5.6 及更早的时代大家最熟悉的写法长这样SET PASSWORD FOR rootlocalhost PASSWORD(newpass);注意PASSWORD()函数在 MySQL 5.7 中被标记为废弃MySQL 8.0 直接移除。今天你在 8.0 里敲这行会见到ERROR 1305之类的报错。新版写法不再需要函数包裹SET PASSWORD FOR rootlocalhost NewPass123!;如果是给自己改当前登录用户也可以简化成SET PASSWORD NewPass123!;2.3 mysqladmin命令行快速改不想进 SQL 交互界面可以直接用mysqladminmysqladmin -u root -pOldPass123 password NewPass123!老密码在-p后面跟着新密码写在最后一个参数。这种方式适合脚本自动化但注意命令行里明文带密码shell 历史记录会留下痕迹生产服务器慎重。2.4 手改 mysql.user 表的坚持派网上大量老文章教你这样USE mysql; UPDATE user SET PasswordPASSWORD(newpass) WHERE Userroot; FLUSH PRIVILEGES;这条链路的隐患在于MySQL 5.7 之后mysql.user表里并不存在可直接填写的Password列实际字段叫authentication_string你 UPDATE 完还要正确地同步插件稍有差错就会变成“密码显示是改了但怎么都登不上”。我早些年吃过这个亏因为照着一篇老文章在 5.7 环境里更新了authentication_string但忘了处理plugin字段结果 root 账户的认证插件和哈希格式不匹配最后只能走重置流程。现在我的立场很明确非紧急救援场景不要直接改表。系统表的结构每个大版本都可能变SQL语句等价性也不如官方封装好的命令可靠。2.5 顺手查看修改结果改完别急着走先确认系统表里到底存了什么SELECT user, host, plugin, authentication_string FROM mysql.user WHERE userroot;在 MySQL 8.0 中plugin字段通常是caching_sha2_passwordauthentication_string是一长串哈希值。确认这两项都对心里才有底。3. 忘记密码的紧急通道skip-grant-tables 与 init-file忘记 root 密码是 DBA 和运维的日常噩梦。此时没有合法登录方式只能靠服务器启动阶段的握手漏洞来做“救援”。配置文件在这里就是完全的主角。3.1 方案一skip-grant-tables 传统救法这个思路很简单让 MySQL 启动时跳过权限验证也就是不加载授权表。做法如下。第一步停掉 MySQL 服务。Linux 上多半是sudo systemctl stop mysqld # 或 sudo /etc/init.d/mysql stop第二步编辑配置文件一般位于/etc/my.cnf或/etc/mysql/my.cnfWindows 下是安装目录里的my.ini在[mysqld]段落下加两行[mysqld] skip-grant-tables skip-networkingskip-networking不是必须但强烈建议加它让 MySQL 只听本机 socket防止绕过认证后开放 TCP 端口被外部扫到。救援期间把自己锁在本机里是基本的安全觉悟。第三步启动服务sudo systemctl start mysqld然后直接免密登录mysql -u root注意此刻你不需要密码因为它根本没查授权表。第四步先刷权限再改密码FLUSH PRIVILEGES; ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY NewPass123!;这里有两个细节值得讲刚进skip-grant-tables模式时权限系统是“不加载”的直接执行ALTER USER经常报“无法修改”或干脆提示相关权限不足。先FLUSH PRIVILEGES把授权表重新加载一遍当前会话才有足够权限改系统表。如果你不指定WITH mysql_native_password执行可能会把 root 的插件重置成默认值某些老客户端会连不上。为了减少变量我习惯在这个场合显式指定原生密码插件完成后再根据业务需要调整。第五步必须要做的收尾删掉配置里的skip-grant-tables和skip-networking重启 MySQL然后正常登录验证mysql -u root -p这里有个非常容易犯的错误改完密码后忘记把skip-grant-tables注释掉直接重启。结果是 MySQL 依然处于跳过认证状态任何用户不需要密码就能登进库相当于把大门拆了。安全审计真要查起来属于重大事故。3.2 方案二init-file 官方推荐的“干净”重置MySQL 官方文档更愿意推荐用init-file方案因为它不需要进入无认证的裸奔状态。原理是mysqld 启动时会按顺序执行init-file指定的 SQL 文件。第一步创建一个文本文件比如放在安全目录sudo vi /var/lib/mysql-files/reset.sql文件内容写ALTER USER rootlocalhost IDENTIFIED BY NewPass123!;如果 MySQL 8.0 中该用户当前的插件需要显式指定也可以写ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY NewPass123!;第二步改配置文件在[mysqld]段加一行[mysqld] init-file/var/lib/mysql-files/reset.sql第三步重启 MySQLsudo systemctl restart mysqldmysqld 在初始化阶段读到这个文件并执行里面的 SQL密码就直接改掉了。启动完成后立刻删除或注释配置里的init-file并删除或清理该 SQL 文件然后再次重启确认mysql -u root -p3.3 两种救援方案的对比维度skip-grant-tablesinit-file原理跳过授权表加载免认证登录启动阶段预执行 SQL 重置密码风险期间无认证容易裸奔较低正常认证流程仍在操作步骤较多要 flush 后再改简单启动即完成对服务的占用需要长期处于停止状态再改只需一次滚动重启适合场景系统已进不去命令极端紧急具备文件操作权限时的常规救援我在真实运维里能走init-file就不走skip-grant-tables。原因很简单前者不需要在“没有认证”的窗口期做太多操作出错概率小得多。4. 配置文件中直接决定密码体验的几个隐藏开关如果说上面是“改密码时怎么用配置文件”那这里就是“配置文件里哪些参数平时就在影响你的密码”。搞懂这些很多看似莫名奇妙的报错会豁然开朗。4.1 默认认证插件default_authentication_pluginMySQL 8.0 开始默认认证插件从mysql_native_password换成了caching_sha2_password。这是为了更强的安全性但也带来一个非常现实的问题老版本客户端、老语言驱动可能不支持新插件导致“密码明明对就是连不上”。你可以在配置文件中强制指定默认插件[mysqld] default-authentication-pluginmysql_native_password或者反过来保持默认但在创建用户时明确指定插件。这玩意儿属于“全局开关”改动前一定要先确认客户端、驱动、中间件的兼容性别为了某台老机器把整个库的默认策略都改掉。4.2 密码策略组件validate_password 系列如果你执行ALTER USER设置123456这种密码得到的报错经常是ERROR 1819 (HY000): Your password does not satisfy the current policy requirements这就是validate_password组件在拦。它同样可以由配置文件控制初始策略。比较老的 MySQL 5.7 时期配置项风格如下[mysqld] plugin-loadvalidate_password.so validate_password_policyMEDIUM validate_password_length8MySQL 8.0 装组件之后系统变量改成了点分隔常见的有[mysqld] validate_password.policyMEDIUM validate_password.length8 validate_password.mixed_case_count1 validate_password.number_count1 validate_password.special_char_count1策略等级一般三档LOW只校验长度MEDIUM长度 数字 大小写/特殊字符组合STRONG在上面基础上还要查字典文件拒绝常见弱密码。日常开发环境、测试库我建议用LOW或MEDIUM就够了生产环境再上STRONG。不然你给业务方开账号时对方随便设个密码就报错运维群里全是你的消息。4.3 救援模式开关skip-grant-tables 的注意事项这个参数严格来说不算“密码策略”但它直接影响密码修改能否成功、能否反复使用。尤其要注意加了它之后很多 SQL 行为会和正常模式不同。最典型的表现是在skip-grant-tables模式下如果你不先FLUSH PRIVILEGES某些版本的 MySQL 会拒绝执行权限相关操作甚至会提示当前用户没有权限。因为授权表没加载服务器不知道该不该信任你。这个坑我亲眼见过不少人踩——明明已经免密登进去了敲ALTER USER却被权限拒绝一时想不通。4.4 客户端侧的配置文件~/.my.cnf改完密码后你可能有多个终端或定时任务在用这套账号。服务器上经常有~/.my.cnf里存了旧的账号密码不更新的话定时任务会在午夜悄悄失败。常见结构[client] userroot passwordNewPass123!注意这里的password是明文权限最好设为仅当前用户可读chmod 600 ~/.my.cnf这是把“双刃剑”用好的关键日常命令行可以免输密码但保护不当就等于把数据库大门钥匙贴门框上。4.5 一张示例配置文件全景把以上参数拼在一起一个典型的、包含密码相关配置的片段长这样[mysqld] datadir/var/lib/mysql socket/var/lib/mysql/mysql.sock # 默认认证插件 # default-authentication-pluginmysql_native_password # 密码策略MySQL 8.0 组件式变量 # validate_password.policyMEDIUM # validate_password.length8 # 忘记密码时的救援开关用完务必注释 # skip-grant-tables # skip-networking # 启动时执行的 SQL 文件用完删除 # init-file/var/lib/mysql-files/reset.sql [client] # 本地命令行免密登录配置按需启用 # userroot # passwordYourPass123!5. 改完不生效排查链路和验证技巧退一万步讲这些命令你都照做了但 MySQL 依然不买账那多半问题出在下面几个容易被忽略的环节。我按实际排查顺序捋一遍。5.1 配置文件究竟被读到了没有很多人改了my.cnf重启后一脸茫然“我为啥没生效” 多半是文件路径不对。Linux 下配置文件有读取顺序的你可以用下面的命令看服务器实际读了哪些mysqld --verbose --help | grep -A 1 Default options输出大致是这样Default options are read from the following files in the given order: /etc/my.cnf /etc/mysql/my.cnf /usr/local/mysql/etc/my.cnf ~/.my.cnf如果在/etc/my.cnf和/etc/mysql/my.cnf里各写了一套配置先被读取的文件的同名参数会有优先权后者可能被覆盖。排查时先确认你改的文件在不在列表里以及有没有被其它文件盖掉。Windows 下更难受my.ini可能不在安装目录而是藏在数据目录或服务启动参数里。建议直接看服务启动命令行sc qc mysql或者看进程参数wmic process where namemysqld.exe get commandline5.2 修改配置后重启失败改完配置一systemctl restart mysqld服务直接起不来或者无限重启。常见原因init-file指向的 SQL 文件权限不对mysqld 用户读不了SQL 文件内容有语法错误启动阶段执行失败配置里同时开了skip-grant-tables和init-file两套逻辑互相干扰。排查时直接看错误日志通常位于/var/log/mysql/error.log或者/var/log/mysqld.logtail -100 /var/log/mysqld.log日志里会告诉你具体是哪个文件、哪段配置没被识别。我遇到过最离谱的一次是配置文件末尾多了个不可见字符mysqld 把参数值截断了折腾了半小时才定位到。5.3 新密码被密码策略卡住前面说过validate_password组件会拦弱密码。你可以在当前会话里先查看策略要求到底是什么SHOW VARIABLES LIKE validate_password%;根据自己的业务需要要么设置一个符合要求的复杂密码要么在确认环境允许的前提下暂时调低策略SET GLOBAL validate_password.policyLOW; SET GLOBAL validate_password.length6;注意SET GLOBAL只在当前运行期生效重启后还是会回到配置文件里的初始值。要永久调整改配置文件里那一段再重启。5.4 客户端连接报错却排除密码本身如果密码改成功但连接工具依旧报错优先怀疑认证插件是否匹配。判断方式如下先用命令行确认当前用户插件SELECT user, host, plugin FROM mysql.user WHERE user你的用户;如果插件是caching_sha2_password而你的老客户端驱动只支持mysql_native_password那就老老实实给这个用户单独指定插件ALTER USER 你的用户host IDENTIFIED WITH mysql_native_password BY 你的新密码;在 MySQL 5.7 时代基本不存在这个烦恼MySQL 8.0 后这是重灾区。尤其是一些用老版本mysql-connector-java、PHP mysqlnd连接的生产系统环境不升级库是 8.0改密码后就等着挨骂吧。5.5 改完以后验证的完整套路我不管给谁处理数据库改完密码都会走一遍完整的验证链路缺一不可第一步本机 socket 登录mysql -u root -p第二步确认当前会话确实是目标账号SELECT CURRENT_USER();第三步检查插件和认证字符串SELECT user, host, plugin, authentication_string FROM mysql.user WHERE userroot;第四步从远程主机用 TCP 协议做一次连接测试确认走了网络栈而不是本地 socket 的特殊权限mysql -h 192.168.x.x -P 3306 -u root -p如果远程连不上但本地没问题你再去看bind-address、防火墙、以及mysql.user表里是否真的存在root%或对应主机条目。很多人在这一步发现的根本不是密码问题而是账户 host 匹配问题。最后多说一句我在实际处理中最大的体会是改密码这件事改之前一定先看版本改之后一定先看配置改完重启前一定再想三秒有没有删掉救援开关。MySQL 5.7 和 8.0 的语法变化、插件机制、系统表结构差异都能让旧文章失效而配置文件是这些差异的集中体现。把“命令 配置 版本”这三件事串成一条线你就能从“照着抄”变成“真正懂”。