MySQL root密码重置：避开那些“改了密码却登不上”的坑
忘记MySQL的root密码，这事儿不少人都遇到过。网上的教程一搜一大把，核心步骤似乎都指向那个经典的 --skip-grant-tables 参数。但为什么照着做，有时能成功，有时却会陷入“改了密码依然登录失败”的怪圈，甚至可能把数据库安全置于险境？今天，我们就来把整个流程掰开揉碎，看看那些容易被忽略的关键细节。
mysqld 启动时加 --skip-grant-tables 能绕过密码验证，但必须配合 --skip-networking
先说一个核心的安全原则：单独使用 --skip-grant-tables 是极其危险的操作。这个参数确实能让你绕过权限表验证，但如果不加上 --skip-networking，MySQL服务依然会监听网络端口。这意味着，任何能连接到这台机器的本地用户，都可能无需密码就长驱直入，直接修改你的权限表——这哪里是重置密码，简直是让数据库门户大开。
实际操作中，很多人遇到的 Access denied for user 'root'@'localhost' 或者改完密码后登录依然失败的窘境，根源往往就在这里。
正确的启动姿势应该是这样：先停掉MySQL服务，然后用下面这行命令启动一个临时的、安全的进程：
mysqld --skip-grant-tables --skip-networking &
这里有几个技术要点需要注意：
- 命令末尾的
&是让进程在后台运行，别漏掉。 - 如果你的MySQL是通过systemd管理的，务必先执行
systemctl stop mysql停掉服务，再手动执行上述命令。别试图去修改service文件临时加参数，因为配置加载顺序可能导致参数失效。
登录后必须用 UPDATE mysql.user 改 authentication_string，不是 password
成功进入无密码模式后，下一个坑在修改密码的SQL语句上。从MySQL 5.7.6版本开始，系统彻底移除了 password 字段，转而使用 authentication_string 来存储密码哈希值。
如果你还在使用老教程里的 SET PASSWORD 或者 UPDATE ... SET password=... 这类语句，操作可能会静默失败，或者把密码写进了错误的字段。最终导致root账户陷入一种“看似空密码，实则无法登录”的诡异状态。
正确的修改命令如下（请务必将‘你的新密码’替换成你设定的强密码）：
USE mysql;
UPDATE user SET authentication_string = PASSWORD('你的新密码') WHERE User = 'root';
FLUSH PRIVILEGES;
这里需要划几个重点：
PASSWORD()函数在MySQL 8.0及以上版本已被废弃。如果你用的是8.0+，更推荐使用ALTER USER 'root'@'localhost' IDENTIFIED BY '新密码';这条语句。FLUSH PRIVILEGES;命令至关重要。它负责将磁盘上的权限表变更刷新到内存缓存中，如果忘了执行，改了也是白改。WHERE User = 'root'这个条件千万别漏，否则你可能一不小心修改了其他用户的密码。
重启服务前务必杀掉 --skip-grant-tables 进程，否则权限系统始终失效
密码改完了，是不是直接重启服务就万事大吉了？且慢，这里还有一个常见的“收尾陷阱”。很多人执行完 FLUSH PRIVILEGES 后，就立刻 systemctl start mysql，结果发现服务要么起不来，要么起来后还是可以免密登录。
问题出在哪？因为你之前手动启动的那个带 --skip-grant-tables 参数的mysqld进程还在后台运行，它占用了端口。此时再用systemd启动，实际上启动的是另一个实例，而你连接的可能依然是那个跳过了所有权限检查的“老进程”。
安全的收尾工作，需要这三步：
- 查进程：执行
ps aux | grep mysqld，找到带有--skip-grant-tables参数的那一行，记下它的进程ID（PID）。 - 杀掉它：使用
kill -9 [PID]命令彻底结束该进程。注意，直接kill进程名可能会误杀，最好通过PID操作。 - 正常启动：最后，再通过
systemctl start mysql或service mysql start以常规方式启动MySQL服务。
验证是否成功，用新密码执行 mysql -u root -p 登录一下，能进去，就说明一切回归正轨了。
8.0+ 用户注意 plugin 字段必须是 caching_sha2_password 或 mysql_native_password
对于MySQL 8.0及更高版本的用户，还有一个版本特性带来的“隐藏关卡”：默认的身份验证插件是 caching_sha2_password。然而，一些旧的客户端（比如某些版本的PHP驱动、Na vicat或者没有显式指定插件的脚本）可能只兼容老的 mysql_native_password 插件。这就导致即使密码百分百正确，连接时也会抛出 Client does not support authentication protocol 这样的错误。
登录后，可以先检查一下root账户使用的插件：
SELECT Host, User, plugin FROM mysql.user WHERE User = 'root';
如果发现 plugin 字段是空的或者是一个非标准值，就需要强制将其设置为兼容的插件：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的新密码';
FLUSH PRIVILEGES;
这一点在Docker容器环境或自动化运维脚本中尤其容易被忽略。当客户端环境不可控时，不显式指定一个广泛兼容的认证插件，后续的连接之路就可能被彻底堵死。
总结一下关键的安全操作流程：mysqld 启动时必须同时使用 --skip-grant-tables 和 --skip-networking 才安全；仅用前者会导致权限表裸奔，改密码后仍无法登录；MySQL 5.7+ 需更新 authentication_string 字段并执行 FLUSH PRIVILEGES；8.0+ 还需确保 root 的 plugin 为 mysql_native_password 或 caching_sha2_password。
