1. 项目概述CentOS 环境下改 MySQL 密码这个需求看着简单但实际上我见过太多人在这一步翻车了。不管是刚在 VMware 里装完 CentOS 7 想配个 LNMP 环境的新手还是用了几年 MySQL 8.0 的老手都有可能在改密码时被各种报错折腾得满头大汗。原因很简单MySQL 的版本在变认证方式在变密码策略也在变网上随便搜到的教程很可能针对的是和你完全不同的版本组合。这次我就把 CentOS 下修改 MySQL 密码这件事彻底拆开讲清楚。核心覆盖三个大场景知道密码但想更新密码、忘了密码需要重置、以及 MySQL 8.0 这个关键版本里那些绕不开的坑。同时会穿插讲清楚 auth_socket 插件、caching_sha2_password、validate_password 组件这些听起来拗口、但实际会卡住你的关键机制。内容既覆盖毕业设计级别的简单需求也覆盖生产环境里需要平滑切换密码的场景适合刚入门 Linux 运维的开发者也适合在公司服务器上动刀前想先查一遍注意事项的工程师。2. 方案选型与前置准备2.1 先搞清楚你的 MySQL 是怎么装的修改密码之前第一件事不是敲命令而是确认 MySQL 的安装方式。不同安装方式导致后续操作权限、socket 文件路径、服务管理命令都不一样这一步搞错后面所有命令都可能是白执行。yum/rpm 安装这是 CentOS 上最常见的安装方式直接用yum install mysql-server或从 MySQL 官方 yum 仓库安装。服务管理用systemctl配置文件在/etc/my.cnf数据目录通常在/var/lib/mysql。源码编译安装自己编译安装的情况多见于对版本有特殊要求的生产环境默认安装路径可能是/usr/local/mysql配置文件可能是/etc/my.cnf也可能是安装目录下的my.cnf。Docker 容器安装这两年越来越多人在 Docker 里跑 MySQL如果改了容器内的 MySQL 密码要注意容器重建后数据是否保留在 volume 里还有端口映射问题。容器内的 MySQL 修改密码方式基本一致但要注意docker exec进容器后可能没有 vi、vim 这些编辑工具。免安装版二进制解压版下载 tar.gz 解压后直接用的方式需要手动初始化数据目录改密码时需要注意mysqld是否已经以正确用户身份运行。这几种安装方式下MySQL 的默认 root 账户授权方式可能不同。比如用 yum 安装在 CentOS 7 上实际上你遇到的第一个坎就是 root 用户通过 socket 连接时用的认证插件可能不是密码而是 auth_socket。这个后面我会详细讲先记住一个原则修改密码前先确认自己能用什么方式连进 MySQL。2.2 工具选型命令行优先修改 MySQL 密码的工具选择很明确优先用 MySQL 自带的命令行工具不要上来就打开 Navicat 或者 MySQL Workbench。原因有三个命令行工具不依赖图形界面服务器上没装桌面环境也能操作而生产服务器几乎都是纯命令行环境。修改密码的过程中通常需要重启 MySQL 服务或者以特殊模式启动这些操作只能通过 shell 完成。Navicat、Workbench 这类图形工具连接 MySQL 时本身就需要密码认证如果你要解决的就是忘记密码这个问题图形工具根本进不去。命令行工具分两类一类是mysql客户端负责连接 MySQL 服务端并执行 SQL另一类是mysqladmin可以远程执行一些管理操作。改密码时mysql是主力mysqladmin可以用来快速测试新密码是否生效。还有一个细节如果服务器上 MySQL 版本是 5.7 或 8.0推荐使用 MySQL 官方自带的mysql_secure_installation脚本来做基础安全配置这个脚本可以顺手把 root 密码设置好。不过这个工具严格来说不是用来改密码的而是一个初始化安全配置向导适合新装 MySQL 后第一次设置密码后面我会提一句。提示如果你的 MySQL 是 Docker 容器方式运行的不要试图到宿主机上用systemctl restart mysqld重启 MySQL正确做法是docker restart 容器名。这个细节能省掉很多不必要的怀疑人生。3. 知道密码的情况下修改密码3.1 标准修改流程假设你现在知道 MySQL 的 root 密码想换成新的强密码这是最简单也最常规的场景。操作分三步走第一步登录 MySQL。命令行输入mysql -u root -p输入当前密码进入 MySQL 交互界面。这一步要注意如果服务器上同时装了 MariaDB 和 MySQLmysql命令可能指向的是 MariaDB 的客户端进错地方是不少见的事故。稳妥的办法是先执行mysql --version看看版本信息。第二步切换到你想要的数据库。不同版本用的库名不同-- MySQL 5.7 及以下版本 USE mysql; -- MySQL 8.0 版本 USE mysql;实际上不管哪个版本mysql库都是存在的只是内部表结构不同。MySQL 8.0 里mysql.user表中的Password字段被移除了改成了authentication_string字段存储密码散列值。第三步执行修改密码的语句。根据版本不同SQL 语法有差异。MySQL 5.7 及以下版本最典型的写法是UPDATE user SET PasswordPASSWORD(新密码) WHERE Userroot; FLUSH PRIVILEGES;这也是网上教程里流传最广的写法但它有两个问题一是PASSWORD()函数在 MySQL 5.7.6 开始就被标记为 deprecated到 8.0 直接被移除了二是直接改mysql.user表在 MySQL 8.0 里会报错因为表结构变了。MySQL 8.0 版本官方推荐的写法是ALTER USER rootlocalhost IDENTIFIED BY 新密码;这个语法同样适用于 MySQL 5.7。所以在任何版本下我都推荐优先用ALTER USER语句它才是跨版本通吃的标准做法。改完之后可以顺手刷新一下权限FLUSH PRIVILEGES;严格来说用ALTER USER改密码后不需要执行FLUSH PRIVILEGES因为它已经直接修改了授权表。但多执行一步没坏处能避免一些边界情况下权限缓存未刷新的问题。修改完成后用新密码重新登录验证一下mysql -u root -p输入新密码能进入就说明修改成功。3.2 不同场景下的账号区分修改密码时有一个细节特别容易踩坑MySQL 的账号是由 用户名 主机 两部分组成的。root账号在 MySQL 里可能是多个条目比如rootlocalhost、root127.0.0.1、root%它们各自有独立的密码。如果应用服务器从 IP 192.168.1.100 连接 MySQL而 MySQL 上只有rootlocalhost这个账号你会发现密码改了之后应用依然报错因为应用连接时实际匹配的是root%或root192.168.1.100。这时候需要查看一下不同的 host 条目SELECT user, host, authentication_string FROM mysql.user WHERE userroot;执行结果会列出所有 root 相关的条目。如果确实存在多个 host 条目修改密码时需要分别处理或者精确指定 hostALTER USER rootlocalhost IDENTIFIED BY 新密码; ALTER USER root% IDENTIFIED BY 新密码;还有一种更隐蔽的情况应用连接时用的账号不是 root而是一个业务账号。这时候去改 root 密码根本没意义。所以动手之前建议先和开发确认应用连接数据库用的到底是哪个账号。3.3 修改密码后的连带影响知道密码、改密码看起来就是两条 SQL 的事但你的工作并没有结束。密码修改后有几个地方是会被震到的。第一个是应用配置。后端服务里写的数据库连接信息不是凭空存在的要么在配置文件里要么在环境变量里要么在配置中心里。如果只是本地测试环境改完密码忘了同步配置文件下次启动服务直接报Access denied for user。我自己的习惯是改完密码后第一时间把这些位置全部同步一遍宁可多花两分钟也不要等第二天线上告警了才想起来。第二个是主从复制。如果当前的 MySQL 环境是主从架构从库通过复制的账号去主库拉取 binlog。主库上复制账号的密码改了从库上配置的复制链路可能直接就断了。从库的报错一般长这样Last_IO_Errno: 1045错误信息会提示Access denied。这时候需要在从库上重新设置 CHANGE MASTER 的密码。第三个是定时备份脚本。很多人习惯在 crontab 里写mysqldump -uroot -p旧密码这样的备份任务改完密码之后这个定时任务就会在凌晨三点安静地失败直到你发现备份文件日期不对。所以改密码之后最好手动跑一次备份脚本确认没问题再走。4. 忘记密码时如何重置4.1 跳过授权表启动 MySQL忘记密码是每个人都会遇到的场景这个场景下你无法通过正常的mysql -u root -p登录正确思路是先停掉 MySQL 服务再用跳过授权表的方式启动此时 MySQL 不再校验密码任何客户端都能直接连进来然后你就可以执行修改密码的语句了。在 CentOS 7/8 上标准的操作流程如下第一步停止 MySQL 服务systemctl stop mysqld如果服务名不对比如有些版本是mysql可以先看下systemctl list-units | grep -i mysql第二步跳过授权表启动。这里有两个方式推荐第一个。方式一使用mysqld_safe启动跳过授权表并跳过网络mysqld_safe --skip-grant-tables --skip-networking --skip-networking这个参数很关键它的作用是让 MySQL 只监听本地 socket不监听 TCP 端口。这样能避免跳过授权表期间局域网里的其他机器也连接进来属于安全加固措施。如果你把 MySQL 跑在公网服务器上这一步千万不能省。方式二直接修改配置文件/etc/my.cnf在[mysqld]段落里加上skip-grant-tables skip-networking然后重启服务systemctl restart mysqld第二种方式的好处是方便收尾改完密码后删除这两行配置再重启就好。但我个人更推荐mysqld_safe方式因为启动参数只对本次启动生效不会污染配置文件改完密码后直接重启服务就能恢复正常模式不会出现配置文件里留着 skip-grant-tables 忘记删掉导致 MySQL 裸奔的低级事故。第三步无密码登录mysql -u root此时不需要输入密码直接进入 MySQL 交互界面。4.2 八零坑跳过授权表后修改密码的报错处理这里要重点提醒如果你在 MySQL 8.0 上执行了--skip-grant-tables然后尝试用下面的语句直接改密码ALTER USER rootlocalhost IDENTIFIED BY 新密码;大概率会得到一个报错ERROR 1290 (HY000): The MySQL server is running with the --skip-grant-tables option so it cannot execute this statement这个报错的意思是在跳过授权表模式下ALTER USER语句不能执行。这其实是 MySQL 的一个保护机制防止在无权限校验的状态下随便改账号信息。MySQL 官方文档里明确写了在--skip-grant-tables模式下很多账户管理相关的语句会被禁用。解决方式有几种。方式一推荐首先执行FLUSH PRIVILEGES让 MySQL 重新加载授权表这样ALTER USER语句就能执行了FLUSH PRIVILEGES; ALTER USER rootlocalhost IDENTIFIED BY 新密码;FLUSH PRIVILEGES会把mysql.user表中的数据重新加载到内存MySQL 会重新进入授权表可用的状态然后你就能正常执行ALTER USER了。方式二直接更新mysql.user表。这个方式在 MySQL 8.0 里也能用因为authentication_string字段仍然存在USE mysql; UPDATE user SET authentication_string WHERE userroot; FLUSH PRIVILEGES;先把密码清空然后以空密码登录再执行ALTER USER设置新密码。这种方式多了一步但兼容性最好。方式三修改配置文件重启服务去掉skip-grant-tables再以正常模式修改密码。这个方式比较繁琐适合实在搞不定上面两种操作时的兜底方案。我个人最常用的组合拳是FLUSH PRIVILEGESALTER USER。一次搞定不用二次重启。4.3 重置密码后的安全收尾密码修改成功后不要急着关终端。先把跳过授权表模式退出来如果用的是mysqld_safe方式直接重启服务systemctl restart mysqld如果用的是改配置文件的方式先把/etc/my.cnf里的skip-grant-tables和skip-networking删掉保存后重启服务。重启之后验证新密码是否生效mysql -u root -p输入新密码登录。如果登录成功再顺手看一下 MySQL 当前监听的端口和网络访问情况SHOW VARIABLES LIKE port; SHOW VARIABLES LIKE skip_networking;确认skip_networking是 OFFMySQL 才能正常提供网络服务。如果还是 ON说明配置文件里的参数没删干净继续排查。提示如果 MySQL 是通过 systemd 管理的某些版本里使用mysqld_safe启动和 systemd 可能有冲突。遇到这种情况直接修改/etc/my.cnf加参数的方式更稳妥不需要跟系统的 service 管理机制较劲。5. MySQL 8.0 环境下的特殊问题处理5.1 默认密码机制MySQL 8.0 在 CentOS 上的安装体验和 5.7 相比有一个非常大的变化初始化时 root 会生成一个临时随机密码而不是像 5.7 之前那样默认为空或者默认是 root。很多新手第一次装 MySQL 8.0看到mysql -u root -p登录失败就觉得是自己操作有问题其实只是没找到临时密码。安装完成后的第一次启动MySQL 会把临时密码写入错误日志文件。在 CentOS 上这个文件通常在/var/log/mysqld.log。查看临时密码的方法grep temporary password /var/log/mysqld.log输出类似[Note] A temporary password is generated for rootlocalhost: f5Xt8kLn#q3a:后面那个字符串就是临时密码。拿到临时密码后登录并修改成自己的密码mysql -u root -p输入临时密码进入 MySQL然后执行ALTER USER rootlocalhost IDENTIFIED BY 你的新密码;但这里通常会遇到第二个坑MySQL 8.0 默认开启了validate_password组件它要求密码必须满足一定的复杂度。直接用123456这种简单密码会收到ERROR 1819 (HY000): Your password does not satisfy the current policy requirements这个报错的原因是默认密码策略等级是 MEDIUM要求密码长度至少 8 位并且包含数字、大小写字母、特殊字符中的至少三类。如果你只是想在本地开发环境里用弱密码有两个办法一是设置一个符合复杂度要求的密码比如Admin123456这种密码同时满足大小写、数字、特殊字符和长度要求。二是临时降低密码策略等级SET GLOBAL validate_password.policy LOW; SET GLOBAL validate_password.length 6;这条命令在 MySQL 8.0 里生效5.7 里对应的变量名需要去掉中间的点写成validate_password_policy和validate_password_length。不过我建议生产环境还是保留默认的强密码策略密码复杂度要求本质上是保护你的数据。5.2 caching_sha2_password 问题MySQL 8.0 把默认认证插件从 5.7 的mysql_native_password换成了caching_sha2_password。这个改变在安全性上是升级但兼容性上带来了麻烦如果你用老版本的客户端连接 MySQL 8.0会直接报错Authentication plugin caching_sha2_password cannot be loaded。改密码的时候也会遇到类似的问题主要体现在你执行完ALTER USER之后应用连不上了。原因就是新密码对应的认证插件是caching_sha2_password而应用的连接驱动比如老版本的 PHP mysqli、Java 的旧版 MySQL Connector/J、Python 的 mysqlclient不认识这个插件。解决方法有三个第一个升级应用端的连接驱动或者客户端工具支持caching_sha2_password就够了这是最彻底的方案。第二个把用户切换回旧的认证插件ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 新密码;这个写法显式指定了认证插件为mysql_native_password适用于因为各种原因暂时没法升级客户端的情况。MySQL 8.0 仍然支持这个插件只是默认不再使用。第三个修改 MySQL 的全局默认认证插件在/etc/my.cnf的[mysqld]段落加default_authentication_pluginmysql_native_password这种方式会影响所有新建用户生产环境不建议全局改除非你已经确认所有客户端都无法支持新插件。修改密码时如果只想改密码但不改认证插件用ALTER USER rootlocalhost IDENTIFIED BY 新密码;如果想同时改密码和认证插件用显式的IDENTIFIED WITH语法。这两种写法的效果差异从实际应用角度看就是客户端能不能连得上。5.3 修改密码后需要同步调整的配置MySQL 8.0 相对比较严格改完密码后往往不只是密码本身发生变化还会影响一些周边配置。my.cnf里如果有skip-grant-tables这个一般只会在忘记密码时临时加上正常使用不应该有一定要删掉。还有init_connect参数如果有特殊设置也顺带看一眼。防火墙层面如果 MySQL 在 CentOS 上开启了远程访问需要确认 3306 端口是放行的。CentOS 7 开始默认使用 firewalld查看和放行端口firewall-cmd --permanent --add-port3306/tcp firewall-cmd --reload firewall-cmd --list-ports如果修改密码后远程连接失败本地却能连接优先检查防火墙状态而不是怀疑密码问题。SELinux 也是一个隐形的坑。CentOS 上 SELinux 默认是 enforcing 模式如果你之前执行过某些自定义配置改了 MySQL 相关的文件上下文可能导致 MySQL 启动失败但日志里看不出明显问题。排查时可以临时用setenforce 0验证如果是 SELinux 导致的再针对性地调整策略。6. 常见问题与排查技巧实录6.1 高频报错速查表我整理了最近两年实际操作和社区答疑里出现频率最高的几个报错按场景分类列了个速查表方便卡住的时候直接对照。报错信息原因分析解决方案Access denied for user rootlocalhost密码错误或 auth_socket 插件拦截导致密码登录无法匹配确认密码检查认证插件忘记密码时走 skip-grant-tables 重置ERROR 1819: Your password does not satisfy the current policy requirements新密码不符合 validate_password 策略要求设置复杂度更高的密码或临时调低策略等级ERROR 1290: Running with --skip-grant-tables so it cannot execute this statement跳过授权表模式下不能执行 ALTER USER先执行 FLUSH PRIVILEGES再执行 ALTER USERERROR 1045: Access denied for user rootlocalhost认证插件不匹配或密码错误常见于 8.0 与旧客户端连接更新客户端驱动显式指定 mysql_native_password 插件ERROR 1130: Host 192.168.x.x is not allowed to connectroot 账号没有允许对应 IP 连接修改用户 host 或创建允许远程连接的新账号Cant connect to local MySQL server through socket /var/lib/mysql/mysql.sockMySQL 服务未启动或 socket 文件路径不对检查服务状态systemctl status mysqld确认 socket 路径mysqld_safe: command not foundPATH 环境变量未包含 MySQL 安装目录使用绝对路径如 /usr/local/mysql/bin/mysqld_safe这些报错看着多但本质都是身份认证、权限范围和资源访问三个维度上的问题。排查时按用户是否存在、密码是否正确、认证插件是否匹配、host 是否被允许、服务是否在运行、防火墙是否放行这个顺序从前往后查90% 的问题能快速定位。6.2 最容易被忽略的 auth_socket 插件在所有身份认证问题里auth_socket 插件是新手最容易卡住的点。它和传统的密码认证完全不同使用这个插件的账号不用输入密码系统直接检查当前 Linux 操作系统用户是不是 MySQL 账号对应的用户。CentOS 上用 yum 安装 MariaDB 或 MySQL 后root 账号经常默认使用 auth_socket 认证。你执行mysql -u root -p提示输入密码输入什么都是错的。实际上正确的登录方式是直接敲mysql -u root不加-p参数直接回车因为系统检测到你是 Linux 的 root 用户就直接让你进了根本不需要密码。这种机制本意是安全的因为它确保了只有登录了操作系统 root 用户的人才能以 MySQL root 身份进入。但如果你要用 Navicat 等工具远程连接 MySQL root 账号就会被 auth_socket 卡住因为它根本没法通过操作系统用户认证。解决方案是把这个账号改成密码认证ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 新密码;执行后mysql -u root不带密码就进不去了必须用mysql -u root -p输入新密码。如果你希望保留本机免密登录的习惯就不要改这个插件如果你需要远程连接就必须改成密码认证。这个权衡要根据实际使用场景来定。6.3 实战排查示例为了更直观地说明排查思路我模拟一次完整的故障排查过程。场景描述CentOS 7.9 服务器MySQL 8.0.28通过 yum 安装。用户反映应用服务器连接 MySQL 报Access denied for user root%但之前一直正常。排查步骤第一步先在 MySQL 服务器本机测试本地登录是否正常mysql -u root -p如果能登录说明 MySQL 服务本身正常问题大概率在账号 host 或认证插件。第二步查看 root 账号的 host 和认证插件SELECT user, host, plugin FROM mysql.user WHERE userroot;执行结果可能是userhostpluginrootlocalhostauth_socketroot%mysql_native_password看到rootlocalhost是 auth_socketroot%是 mysql_native_password。这意味着应用从远程 IP 连接时走的是root%这个条目它用的是密码认证。第三步测试远程连接在应用服务器上执行mysql -h 数据库服务器IP -u root -p发现还是报 Access denied。这时候问题可能是密码被改过也可能是 host 匹配问题。第四步查看 MySQL 的 general log 或 error log。error log 路径可以用SHOW VARIABLES LIKE log_error;在日志里搜索 Access denied 相关的记录确认是不是有人改了密码或者错误日志里是否有其他线索。如果日志显示Access denied for user root192.168.1.50说明这个 IP 不在允许范围内。确认方式是查看root%这个条目是否真的对任意 IP 开放。第五步根据确认的结果执行对应操作如果确认密码被改过用本地登录后重新设置root%的密码。如果确认 host 限制新建账号或修改 host。这个排查流程看起来繁琐但每一步都是在做排除法能把模糊的连不上精确定位到具体原因。实际工作中我建议多用SHOW语句和日志文件不要靠猜。6.4 修改密码时的安全建议写到这里再多说几句安全方面的建议。MySQL 密码修改看似是个小操作但很多时候是在生产环境里进行的安全红线不能碰。备份先行。修改密码前如果条件允许先用 mysqldump 做一次逻辑备份或者至少确认最近有最近的备份。修改密码本身不会导致数据丢失但如果你操作失误比如误删了用户表、误执行了 DROP有备份能救命。最小权限。日常使用不要用 root 账号连接数据库应该创建专用业务账号只授予业务所需的权限。修改 root 密码后应用连接改用业务账号能大大缩小攻击面。给业务账号授权的方式CREATE USER app_user% IDENTIFIED BY 强密码; GRANT SELECT, INSERT, UPDATE, DELETE ON yourapp.* TO app_user%;网络隔离。不要在公网环境直接开放 3306 端口尽量用内网连接或者使用 SSH 隧道。如果确实需要公网访问一定要限制来源 IP配合防火墙规则。定时换密。生产环境的数据库密码建议定期更换并在密码管理工具里统一维护不要写在代码仓库或贴在屏幕边。7. 操作后的验证与经验总结7.1 验证清单改完密码不等于完事我每次都会按下面的清单过一遍确认没有遗漏[ ] 使用新密码本地登录 MySQL确认成功[ ] 在应用服务器上使用新密码远程连接确认成功如果有远程访问需求[ ] 检查应用日志或服务状态确认依赖数据库的服务正常启动并完成连接[ ] 执行SHOW PROCESSLIST确认应用连接已经建立[ ] 检查mysql.user表中目标账号的 plugin 字段确认认证插件符合客户端兼容性[ ] 检查 MySQL error log确认重启后没有新的异常记录[ ] 修改并验证密码后手动执行一次备份脚本确认定时备份任务不会失败这个清单看着长但每项最多花一两分钟能省掉后续很多麻烦。尤其最后一条我吃过亏备份任务在改完密码后的凌晨三点准时失败等到发现问题已经是三天后了。7.2 个人实操心得最后分享几个只有实际踩过坑才会注意到的细节。第一个是ALTER USER和SET PASSWORD的选择。在 MySQL 5.7 时代很多老教程用的是SET PASSWORD FOR rootlocalhost PASSWORD(新密码)这个写法在 MySQL 8.0 里已经被移除会直接报语法错误。统一使用ALTER USER是最稳妥的跨版本兼容性最好。第二个是修改密码前先看plugin字段。MySQL 8.0 默认caching_sha2_password如果你的应用还在用老驱动改密码时最好显式指定mysql_native_password否则改完密码应用就连不上了这个问题排查起来非常折腾人。我见过一个真实案例DBA 改完密码后搞了整整一天最后发现是应用服务器的连接驱动版本太老导致的。第三个是 CentOS 8 和 CentOS 7 的系统管理命令稍有差异但 MySQL 的操作基本一致。CentOS 8 已经到 EOL 了很多源都不再维护如果想新装系统CentOS 7.9 或者直接上其他稳定的发行版会更省心。VMware 里装 CentOS 7 练手时建议最小化安装装完再手动装 MySQL这样能更好理解每一步在做什么。第四个是 Docker 环境下修改 MySQL 密码有一点特殊如果容器删了重建密码改动会丢失除非你挂载了 volume。所以 Docker 部署 MySQL 时务必把/var/lib/mysql挂载出来密码安全问题才能持久化。7.3 密码管理的小技巧现在密码复杂度要求越来越高人脑记一堆乱码不现实推荐用密码管理器统一管理数据库账号密码。另外MySQL 的账号密码不要共享给多个开发人员每个人应该有自己的账号方便审计和追溯。对于 CentOS 服务器上的 .my.cnf 文件如果你的日常操作依赖这个文件来自动登录数据库注意里面保存的是明文密码文件权限一定要设置为 600防止其他系统用户读取chmod 600 ~/.my.cnf修改密码后记得同步更新这个文件里的配置否则下次执行mysql命令时还是会用旧密码尝试连接报错后容易误判问题方向。关于修改 MySQL 密码这件事技巧层面的东西就是这些。只要理解了认证插件机制、版本语法差异、授权表的原理再遇到任何报错都能顺着思路排查而不是网上搜一条试一条。把基础原理吃透比记住一百条命令都管用。
CentOS下MySQL密码修改全指南：从重置到8.0坑详解
1. 项目概述CentOS 环境下改 MySQL 密码这个需求看着简单但实际上我见过太多人在这一步翻车了。不管是刚在 VMware 里装完 CentOS 7 想配个 LNMP 环境的新手还是用了几年 MySQL 8.0 的老手都有可能在改密码时被各种报错折腾得满头大汗。原因很简单MySQL 的版本在变认证方式在变密码策略也在变网上随便搜到的教程很可能针对的是和你完全不同的版本组合。这次我就把 CentOS 下修改 MySQL 密码这件事彻底拆开讲清楚。核心覆盖三个大场景知道密码但想更新密码、忘了密码需要重置、以及 MySQL 8.0 这个关键版本里那些绕不开的坑。同时会穿插讲清楚 auth_socket 插件、caching_sha2_password、validate_password 组件这些听起来拗口、但实际会卡住你的关键机制。内容既覆盖毕业设计级别的简单需求也覆盖生产环境里需要平滑切换密码的场景适合刚入门 Linux 运维的开发者也适合在公司服务器上动刀前想先查一遍注意事项的工程师。2. 方案选型与前置准备2.1 先搞清楚你的 MySQL 是怎么装的修改密码之前第一件事不是敲命令而是确认 MySQL 的安装方式。不同安装方式导致后续操作权限、socket 文件路径、服务管理命令都不一样这一步搞错后面所有命令都可能是白执行。yum/rpm 安装这是 CentOS 上最常见的安装方式直接用yum install mysql-server或从 MySQL 官方 yum 仓库安装。服务管理用systemctl配置文件在/etc/my.cnf数据目录通常在/var/lib/mysql。源码编译安装自己编译安装的情况多见于对版本有特殊要求的生产环境默认安装路径可能是/usr/local/mysql配置文件可能是/etc/my.cnf也可能是安装目录下的my.cnf。Docker 容器安装这两年越来越多人在 Docker 里跑 MySQL如果改了容器内的 MySQL 密码要注意容器重建后数据是否保留在 volume 里还有端口映射问题。容器内的 MySQL 修改密码方式基本一致但要注意docker exec进容器后可能没有 vi、vim 这些编辑工具。免安装版二进制解压版下载 tar.gz 解压后直接用的方式需要手动初始化数据目录改密码时需要注意mysqld是否已经以正确用户身份运行。这几种安装方式下MySQL 的默认 root 账户授权方式可能不同。比如用 yum 安装在 CentOS 7 上实际上你遇到的第一个坎就是 root 用户通过 socket 连接时用的认证插件可能不是密码而是 auth_socket。这个后面我会详细讲先记住一个原则修改密码前先确认自己能用什么方式连进 MySQL。2.2 工具选型命令行优先修改 MySQL 密码的工具选择很明确优先用 MySQL 自带的命令行工具不要上来就打开 Navicat 或者 MySQL Workbench。原因有三个命令行工具不依赖图形界面服务器上没装桌面环境也能操作而生产服务器几乎都是纯命令行环境。修改密码的过程中通常需要重启 MySQL 服务或者以特殊模式启动这些操作只能通过 shell 完成。Navicat、Workbench 这类图形工具连接 MySQL 时本身就需要密码认证如果你要解决的就是忘记密码这个问题图形工具根本进不去。命令行工具分两类一类是mysql客户端负责连接 MySQL 服务端并执行 SQL另一类是mysqladmin可以远程执行一些管理操作。改密码时mysql是主力mysqladmin可以用来快速测试新密码是否生效。还有一个细节如果服务器上 MySQL 版本是 5.7 或 8.0推荐使用 MySQL 官方自带的mysql_secure_installation脚本来做基础安全配置这个脚本可以顺手把 root 密码设置好。不过这个工具严格来说不是用来改密码的而是一个初始化安全配置向导适合新装 MySQL 后第一次设置密码后面我会提一句。提示如果你的 MySQL 是 Docker 容器方式运行的不要试图到宿主机上用systemctl restart mysqld重启 MySQL正确做法是docker restart 容器名。这个细节能省掉很多不必要的怀疑人生。3. 知道密码的情况下修改密码3.1 标准修改流程假设你现在知道 MySQL 的 root 密码想换成新的强密码这是最简单也最常规的场景。操作分三步走第一步登录 MySQL。命令行输入mysql -u root -p输入当前密码进入 MySQL 交互界面。这一步要注意如果服务器上同时装了 MariaDB 和 MySQLmysql命令可能指向的是 MariaDB 的客户端进错地方是不少见的事故。稳妥的办法是先执行mysql --version看看版本信息。第二步切换到你想要的数据库。不同版本用的库名不同-- MySQL 5.7 及以下版本 USE mysql; -- MySQL 8.0 版本 USE mysql;实际上不管哪个版本mysql库都是存在的只是内部表结构不同。MySQL 8.0 里mysql.user表中的Password字段被移除了改成了authentication_string字段存储密码散列值。第三步执行修改密码的语句。根据版本不同SQL 语法有差异。MySQL 5.7 及以下版本最典型的写法是UPDATE user SET PasswordPASSWORD(新密码) WHERE Userroot; FLUSH PRIVILEGES;这也是网上教程里流传最广的写法但它有两个问题一是PASSWORD()函数在 MySQL 5.7.6 开始就被标记为 deprecated到 8.0 直接被移除了二是直接改mysql.user表在 MySQL 8.0 里会报错因为表结构变了。MySQL 8.0 版本官方推荐的写法是ALTER USER rootlocalhost IDENTIFIED BY 新密码;这个语法同样适用于 MySQL 5.7。所以在任何版本下我都推荐优先用ALTER USER语句它才是跨版本通吃的标准做法。改完之后可以顺手刷新一下权限FLUSH PRIVILEGES;严格来说用ALTER USER改密码后不需要执行FLUSH PRIVILEGES因为它已经直接修改了授权表。但多执行一步没坏处能避免一些边界情况下权限缓存未刷新的问题。修改完成后用新密码重新登录验证一下mysql -u root -p输入新密码能进入就说明修改成功。3.2 不同场景下的账号区分修改密码时有一个细节特别容易踩坑MySQL 的账号是由 用户名 主机 两部分组成的。root账号在 MySQL 里可能是多个条目比如rootlocalhost、root127.0.0.1、root%它们各自有独立的密码。如果应用服务器从 IP 192.168.1.100 连接 MySQL而 MySQL 上只有rootlocalhost这个账号你会发现密码改了之后应用依然报错因为应用连接时实际匹配的是root%或root192.168.1.100。这时候需要查看一下不同的 host 条目SELECT user, host, authentication_string FROM mysql.user WHERE userroot;执行结果会列出所有 root 相关的条目。如果确实存在多个 host 条目修改密码时需要分别处理或者精确指定 hostALTER USER rootlocalhost IDENTIFIED BY 新密码; ALTER USER root% IDENTIFIED BY 新密码;还有一种更隐蔽的情况应用连接时用的账号不是 root而是一个业务账号。这时候去改 root 密码根本没意义。所以动手之前建议先和开发确认应用连接数据库用的到底是哪个账号。3.3 修改密码后的连带影响知道密码、改密码看起来就是两条 SQL 的事但你的工作并没有结束。密码修改后有几个地方是会被震到的。第一个是应用配置。后端服务里写的数据库连接信息不是凭空存在的要么在配置文件里要么在环境变量里要么在配置中心里。如果只是本地测试环境改完密码忘了同步配置文件下次启动服务直接报Access denied for user。我自己的习惯是改完密码后第一时间把这些位置全部同步一遍宁可多花两分钟也不要等第二天线上告警了才想起来。第二个是主从复制。如果当前的 MySQL 环境是主从架构从库通过复制的账号去主库拉取 binlog。主库上复制账号的密码改了从库上配置的复制链路可能直接就断了。从库的报错一般长这样Last_IO_Errno: 1045错误信息会提示Access denied。这时候需要在从库上重新设置 CHANGE MASTER 的密码。第三个是定时备份脚本。很多人习惯在 crontab 里写mysqldump -uroot -p旧密码这样的备份任务改完密码之后这个定时任务就会在凌晨三点安静地失败直到你发现备份文件日期不对。所以改密码之后最好手动跑一次备份脚本确认没问题再走。4. 忘记密码时如何重置4.1 跳过授权表启动 MySQL忘记密码是每个人都会遇到的场景这个场景下你无法通过正常的mysql -u root -p登录正确思路是先停掉 MySQL 服务再用跳过授权表的方式启动此时 MySQL 不再校验密码任何客户端都能直接连进来然后你就可以执行修改密码的语句了。在 CentOS 7/8 上标准的操作流程如下第一步停止 MySQL 服务systemctl stop mysqld如果服务名不对比如有些版本是mysql可以先看下systemctl list-units | grep -i mysql第二步跳过授权表启动。这里有两个方式推荐第一个。方式一使用mysqld_safe启动跳过授权表并跳过网络mysqld_safe --skip-grant-tables --skip-networking --skip-networking这个参数很关键它的作用是让 MySQL 只监听本地 socket不监听 TCP 端口。这样能避免跳过授权表期间局域网里的其他机器也连接进来属于安全加固措施。如果你把 MySQL 跑在公网服务器上这一步千万不能省。方式二直接修改配置文件/etc/my.cnf在[mysqld]段落里加上skip-grant-tables skip-networking然后重启服务systemctl restart mysqld第二种方式的好处是方便收尾改完密码后删除这两行配置再重启就好。但我个人更推荐mysqld_safe方式因为启动参数只对本次启动生效不会污染配置文件改完密码后直接重启服务就能恢复正常模式不会出现配置文件里留着 skip-grant-tables 忘记删掉导致 MySQL 裸奔的低级事故。第三步无密码登录mysql -u root此时不需要输入密码直接进入 MySQL 交互界面。4.2 八零坑跳过授权表后修改密码的报错处理这里要重点提醒如果你在 MySQL 8.0 上执行了--skip-grant-tables然后尝试用下面的语句直接改密码ALTER USER rootlocalhost IDENTIFIED BY 新密码;大概率会得到一个报错ERROR 1290 (HY000): The MySQL server is running with the --skip-grant-tables option so it cannot execute this statement这个报错的意思是在跳过授权表模式下ALTER USER语句不能执行。这其实是 MySQL 的一个保护机制防止在无权限校验的状态下随便改账号信息。MySQL 官方文档里明确写了在--skip-grant-tables模式下很多账户管理相关的语句会被禁用。解决方式有几种。方式一推荐首先执行FLUSH PRIVILEGES让 MySQL 重新加载授权表这样ALTER USER语句就能执行了FLUSH PRIVILEGES; ALTER USER rootlocalhost IDENTIFIED BY 新密码;FLUSH PRIVILEGES会把mysql.user表中的数据重新加载到内存MySQL 会重新进入授权表可用的状态然后你就能正常执行ALTER USER了。方式二直接更新mysql.user表。这个方式在 MySQL 8.0 里也能用因为authentication_string字段仍然存在USE mysql; UPDATE user SET authentication_string WHERE userroot; FLUSH PRIVILEGES;先把密码清空然后以空密码登录再执行ALTER USER设置新密码。这种方式多了一步但兼容性最好。方式三修改配置文件重启服务去掉skip-grant-tables再以正常模式修改密码。这个方式比较繁琐适合实在搞不定上面两种操作时的兜底方案。我个人最常用的组合拳是FLUSH PRIVILEGESALTER USER。一次搞定不用二次重启。4.3 重置密码后的安全收尾密码修改成功后不要急着关终端。先把跳过授权表模式退出来如果用的是mysqld_safe方式直接重启服务systemctl restart mysqld如果用的是改配置文件的方式先把/etc/my.cnf里的skip-grant-tables和skip-networking删掉保存后重启服务。重启之后验证新密码是否生效mysql -u root -p输入新密码登录。如果登录成功再顺手看一下 MySQL 当前监听的端口和网络访问情况SHOW VARIABLES LIKE port; SHOW VARIABLES LIKE skip_networking;确认skip_networking是 OFFMySQL 才能正常提供网络服务。如果还是 ON说明配置文件里的参数没删干净继续排查。提示如果 MySQL 是通过 systemd 管理的某些版本里使用mysqld_safe启动和 systemd 可能有冲突。遇到这种情况直接修改/etc/my.cnf加参数的方式更稳妥不需要跟系统的 service 管理机制较劲。5. MySQL 8.0 环境下的特殊问题处理5.1 默认密码机制MySQL 8.0 在 CentOS 上的安装体验和 5.7 相比有一个非常大的变化初始化时 root 会生成一个临时随机密码而不是像 5.7 之前那样默认为空或者默认是 root。很多新手第一次装 MySQL 8.0看到mysql -u root -p登录失败就觉得是自己操作有问题其实只是没找到临时密码。安装完成后的第一次启动MySQL 会把临时密码写入错误日志文件。在 CentOS 上这个文件通常在/var/log/mysqld.log。查看临时密码的方法grep temporary password /var/log/mysqld.log输出类似[Note] A temporary password is generated for rootlocalhost: f5Xt8kLn#q3a:后面那个字符串就是临时密码。拿到临时密码后登录并修改成自己的密码mysql -u root -p输入临时密码进入 MySQL然后执行ALTER USER rootlocalhost IDENTIFIED BY 你的新密码;但这里通常会遇到第二个坑MySQL 8.0 默认开启了validate_password组件它要求密码必须满足一定的复杂度。直接用123456这种简单密码会收到ERROR 1819 (HY000): Your password does not satisfy the current policy requirements这个报错的原因是默认密码策略等级是 MEDIUM要求密码长度至少 8 位并且包含数字、大小写字母、特殊字符中的至少三类。如果你只是想在本地开发环境里用弱密码有两个办法一是设置一个符合复杂度要求的密码比如Admin123456这种密码同时满足大小写、数字、特殊字符和长度要求。二是临时降低密码策略等级SET GLOBAL validate_password.policy LOW; SET GLOBAL validate_password.length 6;这条命令在 MySQL 8.0 里生效5.7 里对应的变量名需要去掉中间的点写成validate_password_policy和validate_password_length。不过我建议生产环境还是保留默认的强密码策略密码复杂度要求本质上是保护你的数据。5.2 caching_sha2_password 问题MySQL 8.0 把默认认证插件从 5.7 的mysql_native_password换成了caching_sha2_password。这个改变在安全性上是升级但兼容性上带来了麻烦如果你用老版本的客户端连接 MySQL 8.0会直接报错Authentication plugin caching_sha2_password cannot be loaded。改密码的时候也会遇到类似的问题主要体现在你执行完ALTER USER之后应用连不上了。原因就是新密码对应的认证插件是caching_sha2_password而应用的连接驱动比如老版本的 PHP mysqli、Java 的旧版 MySQL Connector/J、Python 的 mysqlclient不认识这个插件。解决方法有三个第一个升级应用端的连接驱动或者客户端工具支持caching_sha2_password就够了这是最彻底的方案。第二个把用户切换回旧的认证插件ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 新密码;这个写法显式指定了认证插件为mysql_native_password适用于因为各种原因暂时没法升级客户端的情况。MySQL 8.0 仍然支持这个插件只是默认不再使用。第三个修改 MySQL 的全局默认认证插件在/etc/my.cnf的[mysqld]段落加default_authentication_pluginmysql_native_password这种方式会影响所有新建用户生产环境不建议全局改除非你已经确认所有客户端都无法支持新插件。修改密码时如果只想改密码但不改认证插件用ALTER USER rootlocalhost IDENTIFIED BY 新密码;如果想同时改密码和认证插件用显式的IDENTIFIED WITH语法。这两种写法的效果差异从实际应用角度看就是客户端能不能连得上。5.3 修改密码后需要同步调整的配置MySQL 8.0 相对比较严格改完密码后往往不只是密码本身发生变化还会影响一些周边配置。my.cnf里如果有skip-grant-tables这个一般只会在忘记密码时临时加上正常使用不应该有一定要删掉。还有init_connect参数如果有特殊设置也顺带看一眼。防火墙层面如果 MySQL 在 CentOS 上开启了远程访问需要确认 3306 端口是放行的。CentOS 7 开始默认使用 firewalld查看和放行端口firewall-cmd --permanent --add-port3306/tcp firewall-cmd --reload firewall-cmd --list-ports如果修改密码后远程连接失败本地却能连接优先检查防火墙状态而不是怀疑密码问题。SELinux 也是一个隐形的坑。CentOS 上 SELinux 默认是 enforcing 模式如果你之前执行过某些自定义配置改了 MySQL 相关的文件上下文可能导致 MySQL 启动失败但日志里看不出明显问题。排查时可以临时用setenforce 0验证如果是 SELinux 导致的再针对性地调整策略。6. 常见问题与排查技巧实录6.1 高频报错速查表我整理了最近两年实际操作和社区答疑里出现频率最高的几个报错按场景分类列了个速查表方便卡住的时候直接对照。报错信息原因分析解决方案Access denied for user rootlocalhost密码错误或 auth_socket 插件拦截导致密码登录无法匹配确认密码检查认证插件忘记密码时走 skip-grant-tables 重置ERROR 1819: Your password does not satisfy the current policy requirements新密码不符合 validate_password 策略要求设置复杂度更高的密码或临时调低策略等级ERROR 1290: Running with --skip-grant-tables so it cannot execute this statement跳过授权表模式下不能执行 ALTER USER先执行 FLUSH PRIVILEGES再执行 ALTER USERERROR 1045: Access denied for user rootlocalhost认证插件不匹配或密码错误常见于 8.0 与旧客户端连接更新客户端驱动显式指定 mysql_native_password 插件ERROR 1130: Host 192.168.x.x is not allowed to connectroot 账号没有允许对应 IP 连接修改用户 host 或创建允许远程连接的新账号Cant connect to local MySQL server through socket /var/lib/mysql/mysql.sockMySQL 服务未启动或 socket 文件路径不对检查服务状态systemctl status mysqld确认 socket 路径mysqld_safe: command not foundPATH 环境变量未包含 MySQL 安装目录使用绝对路径如 /usr/local/mysql/bin/mysqld_safe这些报错看着多但本质都是身份认证、权限范围和资源访问三个维度上的问题。排查时按用户是否存在、密码是否正确、认证插件是否匹配、host 是否被允许、服务是否在运行、防火墙是否放行这个顺序从前往后查90% 的问题能快速定位。6.2 最容易被忽略的 auth_socket 插件在所有身份认证问题里auth_socket 插件是新手最容易卡住的点。它和传统的密码认证完全不同使用这个插件的账号不用输入密码系统直接检查当前 Linux 操作系统用户是不是 MySQL 账号对应的用户。CentOS 上用 yum 安装 MariaDB 或 MySQL 后root 账号经常默认使用 auth_socket 认证。你执行mysql -u root -p提示输入密码输入什么都是错的。实际上正确的登录方式是直接敲mysql -u root不加-p参数直接回车因为系统检测到你是 Linux 的 root 用户就直接让你进了根本不需要密码。这种机制本意是安全的因为它确保了只有登录了操作系统 root 用户的人才能以 MySQL root 身份进入。但如果你要用 Navicat 等工具远程连接 MySQL root 账号就会被 auth_socket 卡住因为它根本没法通过操作系统用户认证。解决方案是把这个账号改成密码认证ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 新密码;执行后mysql -u root不带密码就进不去了必须用mysql -u root -p输入新密码。如果你希望保留本机免密登录的习惯就不要改这个插件如果你需要远程连接就必须改成密码认证。这个权衡要根据实际使用场景来定。6.3 实战排查示例为了更直观地说明排查思路我模拟一次完整的故障排查过程。场景描述CentOS 7.9 服务器MySQL 8.0.28通过 yum 安装。用户反映应用服务器连接 MySQL 报Access denied for user root%但之前一直正常。排查步骤第一步先在 MySQL 服务器本机测试本地登录是否正常mysql -u root -p如果能登录说明 MySQL 服务本身正常问题大概率在账号 host 或认证插件。第二步查看 root 账号的 host 和认证插件SELECT user, host, plugin FROM mysql.user WHERE userroot;执行结果可能是userhostpluginrootlocalhostauth_socketroot%mysql_native_password看到rootlocalhost是 auth_socketroot%是 mysql_native_password。这意味着应用从远程 IP 连接时走的是root%这个条目它用的是密码认证。第三步测试远程连接在应用服务器上执行mysql -h 数据库服务器IP -u root -p发现还是报 Access denied。这时候问题可能是密码被改过也可能是 host 匹配问题。第四步查看 MySQL 的 general log 或 error log。error log 路径可以用SHOW VARIABLES LIKE log_error;在日志里搜索 Access denied 相关的记录确认是不是有人改了密码或者错误日志里是否有其他线索。如果日志显示Access denied for user root192.168.1.50说明这个 IP 不在允许范围内。确认方式是查看root%这个条目是否真的对任意 IP 开放。第五步根据确认的结果执行对应操作如果确认密码被改过用本地登录后重新设置root%的密码。如果确认 host 限制新建账号或修改 host。这个排查流程看起来繁琐但每一步都是在做排除法能把模糊的连不上精确定位到具体原因。实际工作中我建议多用SHOW语句和日志文件不要靠猜。6.4 修改密码时的安全建议写到这里再多说几句安全方面的建议。MySQL 密码修改看似是个小操作但很多时候是在生产环境里进行的安全红线不能碰。备份先行。修改密码前如果条件允许先用 mysqldump 做一次逻辑备份或者至少确认最近有最近的备份。修改密码本身不会导致数据丢失但如果你操作失误比如误删了用户表、误执行了 DROP有备份能救命。最小权限。日常使用不要用 root 账号连接数据库应该创建专用业务账号只授予业务所需的权限。修改 root 密码后应用连接改用业务账号能大大缩小攻击面。给业务账号授权的方式CREATE USER app_user% IDENTIFIED BY 强密码; GRANT SELECT, INSERT, UPDATE, DELETE ON yourapp.* TO app_user%;网络隔离。不要在公网环境直接开放 3306 端口尽量用内网连接或者使用 SSH 隧道。如果确实需要公网访问一定要限制来源 IP配合防火墙规则。定时换密。生产环境的数据库密码建议定期更换并在密码管理工具里统一维护不要写在代码仓库或贴在屏幕边。7. 操作后的验证与经验总结7.1 验证清单改完密码不等于完事我每次都会按下面的清单过一遍确认没有遗漏[ ] 使用新密码本地登录 MySQL确认成功[ ] 在应用服务器上使用新密码远程连接确认成功如果有远程访问需求[ ] 检查应用日志或服务状态确认依赖数据库的服务正常启动并完成连接[ ] 执行SHOW PROCESSLIST确认应用连接已经建立[ ] 检查mysql.user表中目标账号的 plugin 字段确认认证插件符合客户端兼容性[ ] 检查 MySQL error log确认重启后没有新的异常记录[ ] 修改并验证密码后手动执行一次备份脚本确认定时备份任务不会失败这个清单看着长但每项最多花一两分钟能省掉后续很多麻烦。尤其最后一条我吃过亏备份任务在改完密码后的凌晨三点准时失败等到发现问题已经是三天后了。7.2 个人实操心得最后分享几个只有实际踩过坑才会注意到的细节。第一个是ALTER USER和SET PASSWORD的选择。在 MySQL 5.7 时代很多老教程用的是SET PASSWORD FOR rootlocalhost PASSWORD(新密码)这个写法在 MySQL 8.0 里已经被移除会直接报语法错误。统一使用ALTER USER是最稳妥的跨版本兼容性最好。第二个是修改密码前先看plugin字段。MySQL 8.0 默认caching_sha2_password如果你的应用还在用老驱动改密码时最好显式指定mysql_native_password否则改完密码应用就连不上了这个问题排查起来非常折腾人。我见过一个真实案例DBA 改完密码后搞了整整一天最后发现是应用服务器的连接驱动版本太老导致的。第三个是 CentOS 8 和 CentOS 7 的系统管理命令稍有差异但 MySQL 的操作基本一致。CentOS 8 已经到 EOL 了很多源都不再维护如果想新装系统CentOS 7.9 或者直接上其他稳定的发行版会更省心。VMware 里装 CentOS 7 练手时建议最小化安装装完再手动装 MySQL这样能更好理解每一步在做什么。第四个是 Docker 环境下修改 MySQL 密码有一点特殊如果容器删了重建密码改动会丢失除非你挂载了 volume。所以 Docker 部署 MySQL 时务必把/var/lib/mysql挂载出来密码安全问题才能持久化。7.3 密码管理的小技巧现在密码复杂度要求越来越高人脑记一堆乱码不现实推荐用密码管理器统一管理数据库账号密码。另外MySQL 的账号密码不要共享给多个开发人员每个人应该有自己的账号方便审计和追溯。对于 CentOS 服务器上的 .my.cnf 文件如果你的日常操作依赖这个文件来自动登录数据库注意里面保存的是明文密码文件权限一定要设置为 600防止其他系统用户读取chmod 600 ~/.my.cnf修改密码后记得同步更新这个文件里的配置否则下次执行mysql命令时还是会用旧密码尝试连接报错后容易误判问题方向。关于修改 MySQL 密码这件事技巧层面的东西就是这些。只要理解了认证插件机制、版本语法差异、授权表的原理再遇到任何报错都能顺着思路排查而不是网上搜一条试一条。把基础原理吃透比记住一百条命令都管用。