开篇
服务器MySQL登录密码忘记，最快的解决办法不是暴力破解，而是临时跳过权限验证直接重置密码。 整个过程不需要重装数据库，不需要删除数据文件，按照下方路径操作,10分钟内就能让系统重新认你当主人。
mysql忘记密码怎么重置：跳过权限验证的完整流程
很多人一听“跳过权限验证”就紧张，觉得是把数据库大门敞开了，其实这套操作是MySQL官方认可的应急方案，核心思路就一句大白话：先让数据库不检查密码，等进去把新密码设好,再把安全检查开关打开。
停止数据库服务
在处理密码这件事之前，先把MySQL服务停下来，用systemd管理服务的Linux发行版,执行下面这条命令：
systemctl stop mysqld如果你的系统是CentOS 6时代的老环境，或者用service命令管理服务,就换成：
service mysql stop停止服务这一步挺关键，不然后面启动临时模式时，端口被旧进程占着，新进程起不来，如果你用的是宝塔面板这类可视化工具，直接在面板的“软件商店 → MySQL → 停止”点击即可,效果一样。
临时跳过授权表启动
这是整个重置流程的核心环节，以跳过授权表的方式启动MySQL，相当于给数据库发了一张“免检通行证”，启动后任何客户端都能直接连接,不需要密码。
mysqld_safe --skip-grant-tables &这是一条经典命令，缺点是mysqld_safe在部分新版MySQL 8.x发行版中位置有变化，如果你的系统提示找不到命令,可以用另一种思路：
mysqld --skip-grant-tables --skip-networking &强烈建议加上–skip-networking参数，加了它，数据库只允许本机通过socket文件连接，外部网络访问直接被拒,防止跳过授权表的窗口期被别有用心的人利用。
进入MySQL重置root密码
服务以跳过授权表模式启动后，用root用户直接登录,这时候不需要密码：
mysql -uroot看到mysql>提示符后，执行如下几条SQL,把root的新密码写进去：
FLUSH PRIVILEGES;
ALTER USER 'root'@'localhost' IDENTIFIED BY '你的新密码';
FLUSH PRIVILEGES;第一条FLUSH PRIVILEGES是为了让MySQL重新加载授权表，把skip-grant-tables的“免检模式”立刻关闭，如果跳过这一步直接执行ALTER USER，可能会报错，提示“Unknown column ‘authentication_string’”或者权限不足。
如果你的MySQL版本比较老，是5.6或5.7的早期小版本，ALTER USER语法可能不被支持,那就用UPDATE方式：
USE mysql;
UPDATE user SET authentication_string=PASSWORD('你的新密码') WHERE User='root';
FLUSH PRIVILEGES;注意，5.7以上版本的user表里authentication_string字段存的是哈希值，不能直接填明文，PASSWORD()函数在老版本中可用，到了MySQL 8.0这个函数被移除了，只用ALTER USER语法。
重启数据库验证新密码
密码改完了，把临时模式关掉,恢复正常启动：
kill [刚才mysqld_safe进程的PID]
systemctl start mysqld然后用新密码验证登录：
mysql -uroot -p输入你刚设置的密码，能进去就说明密码重置成功,进系统后顺手执行一下：
SHOW VARIABLES LIKE 'validate_password%';这条命令能查看当前密码策略强度要求，如果你的新密码太简单，比如纯数字“123456”，修改时会被策略拦下来，就需要先调低密码策略等级再改,或者直接找个符合策略的复杂密码。
linux服务器mysql密码找回：从停止服务到重启验证
上面讲的这套流程，在Linux服务器上跑得最顺，不同发行版之间细节稍有差异,这里分场景说清楚。
CentOS / RHEL 系列
CentOS系用的是mysql或mariadb，服务名可能叫mysqld也可能叫mariadb,先确认你机器上装的是哪个：
rpm -qa | grep -i -E "mysql|mariadb"看到输出结果后，再决定执行systemctl stop mysqld还是systemctl stop mariadb，CentOS 7以上版本建议使用mysqld –skip-grant-tables方式启动，因为mysqld_safe脚本有时候不在PATH路径中，得全路径指定,比较麻烦。
Ubuntu / Debian 系列
Ubuntu上用debian-sys-maint用户维护数据库，重置root密码前，先看一下/etc/mysql/debian.cnf这个文件，里面保存了维护账号的密码，如果你能sudo cat查看这个文件，那还有一种更省事的重置方式：直接用debian.cnf里的账号登录MySQL，再执行ALTER USER改root密码,不用走跳过授权表那套流程。
云服务器RDS数据库的“特殊通道”
如果你用的是简米云RDS、酷番云TDSQL这类云托管的MySQL，没有服务器root权限，更不可能去改配置文件，这种场景下，直接在云控制台的实例详情页找到“重置密码”按钮，输入新密码后提交即可，云厂商会在后台自动完成权限重置，通常不需要重启实例，业务影响很小，大量中小企业的服务器mysql登录密码忘记场景，其实有一半发生在自建数据库上，另一半是RDS，两类场景的处理路径完全不同,先分清自己属于哪一种再动手。
不重启服务也能重置密码：init-file方式
跳过低权限表的方式需要重启数据库，如果你的MySQL正在跑重要的线上业务，停一次服务可能造成连接超时甚至数据写入中断,有没有不重启的办法？
MySQL提供了init-file参数，用它可以在数据库启动时自动执行一个SQL脚本，操作思路是：写一个包含ALTER USER语句的SQL文件，把init-file指向这个文件，然后重启数据库，MySQL在启动阶段会执行这个文件里的SQL,完成密码修改后再正常启动。
步骤如下：
- 创建一个文本文件，tmp/mysql-reset.sql，内容就一行：
ALTER USER 'root'@'localhost' IDENTIFIED BY '你的新密码'; - 把文件权限改成仅root可读：
chmod 600 /tmp/mysql-reset.sql - 修改MySQL配置文件/etc/my.cnf，在[mysqld]段下加一行：
init-file=/tmp/mysql-reset.sql - 重启MySQL服务，执行systemctl restart mysqld
- 登录成功后，把配置文件和SQL文件都删掉，init-file配置也要移除
这种方式相比skip-grant-tables，安全性稍好一些，因为SQL文件里的密码只执行一次，启动完成后不再保留，但核心代价同样是需要重启服务，业内专家的共识是，init-file方式更适合生产环境,因为不会出现授权表完全放开的危险窗口。
重置密码后为什么连不上：常见踩坑排查
重置完密码，高高兴兴敲下mysql -uroot -p，却看到Access denied，这种挫败感经历过的人都懂，遇到这类情况,优先排查以下几个点。
密码策略拦住了你的新密码
MySQL 8.0默认安装后，validate_password组件是激活状态，要求密码长度至少8位，必须包含大小写字母、数字和特殊字符，如果你在ALTER USER时设置的密码不符合要求，报错信息会直接提示Password does not satisfy current policy requirements，解决办法不是硬凑一个复杂密码,而是先执行：
SHOW VARIABLES LIKE 'validate_password%';查看当前策略的validate_password.policy值，如果只是想快速重置,先把策略调低：
SET GLOBAL validate_password.policy = LOW;
SET GLOBAL validate_password.length = 6;然后再执行ALTER USER，改完后再把策略恢复成原样,防止数据库处于薄弱状态。
root账号的host限制
如果你之前一直用root@localhost登录，重置密码时也改的是’root’@’localhost’，这条记录没毛病，但如果你试图用TCP/IP从远程连接，MySQL会匹配到其他host记录，root’@’%’或者’root’@’192.168.1.%’，这些记录的密码没变，自然连不上,需要确认现有root账号：
SELECT user, host, authentication_string FROM mysql.user WHERE user='root';把需要远程登录的host对应记录的密码也改掉，或者只保留localhost,改用专用账号远程连接。
认证插件不兼容
MySQL 8.0默认用caching_sha2_password认证，而很多老版本客户端工具，比如PHP 5.6内置的mysqlnd，只认识mysql_native_password，重置密码时,单独指定认证插件可以解决这类兼容问题：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的新密码';
老客户端连接时报错“Authentication plugin ‘caching_sha2_password’ cannot be loaded”，基本就是认证插件不匹配，行业共识是，新环境尽量用8.0默认插件，旧客户端需要兼容时，在特权账号上单独设置mysql_native_password,不影响整体安全性。
未来如何避免再次陷入密码遗忘困局
密码这事，遗忘是常态，不是意外，与其每次折腾重置流程,不如在日常运维中建立一套防遗忘机制。
- 用密码管理工具托管所有数据库账号，比如KeePass、LastPass、1Password，生成随机强密码并加密存储，不需要自己脑记
- 开启MySQL审计日志，记录所有DDL和DCL操作，将来密码变动有迹可循，不至于哪天被人改了自己都不知道
- 在公司的内部Wiki或堡垒机系统中，建立数据库账号台账，记录账号、权限边界、最近修改时间、审批人
- 设置周期性密码轮换，比如每90天安排一次密码更新，更新过程走脚本自动化，避免频繁手改导致混乱
- 为root账号设定一套应急密码信封，放在公司保险柜或加密的团队密码库中，只有运维负责人知晓
做好这几点，以后几乎不会再用到跳过授权表这套紧急方案，密码管理本质上是对运维习惯的管理，多数情况下密码“忘记”不是记忆力问题,而是没有一套可靠的记录体系。
Q&A：服务器mysql密码遗忘高频问题精解
服务器mysql登录密码忘记了怎么办，重置过程会影响业务吗？
重置密码需要重启MySQL服务，重启期间数据库连接会中断，如果业务具备数据库重连机制，应用恢复时间在秒级；如果没有重连机制，可能需要重启应用才能恢复，尽量在业务低峰期操作，比如凌晨2点到5点之间，数据文件本身不会受到任何影响,密码重置不涉及数据修改。
如何验证重置后的MySQL密码强度是否符合安全要求？
登录MySQL后执行SHOW VARIABLES LIKE ‘validate_password%’;可以查看当前密码策略参数，如果你希望root密码强度强制符合企业规范，比如至少12位且包含三类字符，修改全局变量validate_password.policy和validate_password.length即可，密码策略只对新设置的密码生效,老密码不会自动触发重新校验。
重置密码后，之前业务配置里的旧数据库密码怎么处理？
业务配置文件、环境变量、编排脚本中凡是写死旧密码的地方全部要同步修改，否则应用启动时还会拿旧密码去连接，导致认证失败，修改范围包括环境变量中的配置项、配置文件、云原生环境中的Secret，改完后重启应用实例才能让新配置生效，很多场景下，MySQL服务器密码重置本身只需要几分钟,但全链路配置同步可能要花费数小时。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e6%9c%8d%e5%8a%a1%e5%99%a8mysql%e5%af%86%e7%a0%81%e5%bf%98%e4%ba%86%e6%80%8e%e4%b9%88%e6%94%b9%ef%bc%8croot%e5%af%86%e7%a0%81%e5%bf%98%e8%ae%b0%e5%a6%82%e4%bd%95%e9%87%8d%e7%bd%ae/
