1. 重置前必须搞清楚的几个前提
先说个真实场景。某天早上我接到消息：一台 Windows 服务器上的业务系统突然连不上数据库了，排查下来是 MySQL 的 root 密码不知道被谁改过，试遍了常见组合都不对。更尴尬的是，这台机器的 MySQL 用了很久，密码存在某个同事的记事本里，人已经离职了。没办法，只能走密码重置这条路。
很多第一次遇到这个问题的人，第一反应是“卸载重装”。如果 MySQL 里没有重要数据，或者只是本地开发环境，重新装一个确实省事。但生产环境或数据库里有大量业务数据时，卸载重装等于给自己挖坑——不仅要重新配置 my.ini、重导数据，还容易造成数据丢失。真正的正路，是利用 MySQL 自身的启动机制重置密码。
在动手之前，有三件事必须想清楚。
1.1 先理解“忘记密码”背后的机制
MySQL 的用户账号和密码信息存放在 mysql 库的 user 表里。平时你输入密码登录，MySQL 会去查这张表，比对用户名、主机、加密后的密码串，全部匹配才放行。
所谓“重置密码”，本质上就是绕开这个校验过程，或者直接修改这张表里的密码字段。我们常用的两种思路，对应的就是这两种机制：
- 跳过授权表启动。让 MySQL 启动时不加载权限校验逻辑，此时任何本机用户都能以 root 身份进入，然后手动改掉 user 表里的密码。
- 用初始化文件启动。MySQL 支持在启动时执行一个 SQL 脚本文件，我们写一条修改密码的语句放进这个文件里，启动后它会自动执行。
理解了机制，后面所有操作就都能串起来了。
1.2 确认你属于哪种“忘密码”状态
在动手前，先花两分钟确认当前状态，不同状态对应的处理方式差别很大：
- 完全不知道 root 密码，且没有其他可登录的账号。走标准重置流程，也就是下面要详述的步骤。
- 你有某个普通账号的密码，但它没有修改 root 密码的权限。这种情况其实比较少见，因为普通账号的授权通常有限。如果刚好这个账号有 UPDATE 权限且作用在 mysql.user 表上，理论上也能改 root，但现实中很少见，不建议指望它。
- 你记得密码，但密码中包含特殊字符导致连接工具无法登录。这根本不算忘记，是转义问题，排查连接字符串即可，不需要重置。
绝大多数场景都是第一种。这篇文章主要针对的就是“完全不知道 root 密码”的情况。
1.3 Windows 平台的特殊之处
在 Linux 上重置 MySQL 密码，只需要一个具有 sudo 权限的账号，然后停服务、改配置、起服务，一气呵成。Windows 上稍微麻烦一点，有这么几个特殊点：
必须以管理员身份运行命令行窗口。无论是停服务、启动 mysqld，还是后续的修改操作，权限不够都会报错或没反应。右键点击“命令提示符”或 PowerShell，选择“以管理员身份运行”。这一条如果忽略，后面每一步都可能出问题。
MySQL 的安装方式不同，重置路径也不同。有些人用的是 MSI 安装包，装完自动注册成 Windows 服务；有些人直接解压免安装版，每次用 mysqld 手动启动；还有人用的是 XAMPP、WAMP 这类集成环境。不同安装方式，服务的名字、配置文件的位置、启动命令都不一样，必须提前确认。
版本差异很大。MySQL 5.7 和 8.0 在重置密码时的 SQL 语句不一样，甚至 8.0 的小版本之间也有细微差别。下文会单独区分说明。
这几个前提看起来简单，但很多人就是栽在这里。有一次我看到一篇文章教人用UPDATE mysql.user SET Password=PASSWORD('xxx')去修改密码，这在 MySQL 5.7 及以前确实有效，但放到 8.0 上会直接报错：Column 'Password' is not updatable。原因很简单，8.0 里 user 表已经删掉了 Password 这一列，改成了 authentication_string。版本不对，SQL 语句就不对。
2. 环境检查与启动方式判断
拿到一台忘记密码的 Windows 机器，第一件事不是急着敲命令，而是先摸清环境。我说的环境包括三部分：MySQL 版本、安装方式、配置文件位置。这三样确定之前，一切“标准化操作”都可能是无效操作。
2.1 确认版本与安装方式
如果你能通过某种方式（比如一台能正常登录的应用服务器）间接拿到 MySQL 的版本号，那最好。如果拿不到，就直接去安装目录里找。
MySQL 安装目录下一般会有bin文件夹，里面放着mysqld.exe和mysql.exe。在 Windows 上，MySQL 的安装目录通常是C:\Program Files\MySQL\MySQL Server 8.0\或C:\Program Files\MySQL\MySQL Server 5.7\。看到目录名里的 5.7 或 8.0，版本就清楚了。
如果是免安装版，目录结构通常是这样的：一个主目录，里面有bin、lib、share、my.ini或my.cnf等文件和文件夹。集成环境（XAMPP 等）则有自己的目录结构，MySQL 的 bin 目录通常会被放在C:\xampp\mysql\bin这样，配置文件一般叫my.ini。
确认版本之后，接下来的操作会分成两条线：MySQL 5.7 及以前一条线，MySQL 8.0 及以上一条线。后面我会把两条线的差异都写清楚。
2.2 找到并检查 my.ini 配置文件
my.ini 是 MySQL 在 Windows 下的主配置文件。它的位置有几种可能：
- 安装版默认放安装目录下，或者
C:\ProgramData\MySQL\MySQL Server 8.0\（注意 ProgramData 默认是隐藏的）。 - 免安装版通常就在解压目录的根目录下。
- 集成环境一般在环境的主目录下。
如果找不到，可以打开服务管理器（Win + R输入services.msc），找到名字里带 MySQL 的服务，右键查看属性，里面有一行“可执行文件的路径”，例如：
"C:\Program Files\MySQL\MySQL Server 8.0\bin\mysqld.exe" --defaults-file="C:\ProgramData\MySQL\MySQL Server 8.0\my.ini" MySQL80--defaults-file参数指向的就是当前生效的配置文件。这个信息非常关键，因为后续启动 mysqld 时，如果指定了不同的配置文件，行为会完全不同。
找到 my.ini 后，打开它，检查里面有没有这几项配置：
[mysqld] port=3306 datadir=C:/ProgramData/MySQL/MySQL Server 8.0/Data重点是确认datadir指向的位置。这是一个很多人踩过的坑：重置过程中如果搞错了数据目录，启动后可能连不上原有的数据，甚至出现“找不到 mysql 库”的诡异报错。
2.3 停止 MySQL 服务的正确姿势
重置密码时，必须先停掉正在运行的 MySQL 服务，再用特殊方式启动。停服务的命令很简单：
net stop mysql但如果服务名不叫 mysql，这条命令会包“服务名无效”。更稳妥的做法是先用这个命令确定服务名：
sc query | findstr /i mysql输出里能看到 SERVICE_NAME，那就是准确的服务名。比如常见的 MySQL80，那停止命令就是net stop MySQL80。
有时候net stop会卡住，提示“服务正在启动或停止中”，尤其是 MySQL 正在被业务连接时。这时不要反复重试，先排查谁在占用。可以打开任务管理器，看进程里有没有 mysqld.exe，直接结束进程通常也能解决问题。但要注意，强制结束进程可能导致 innodb 表空间未正常关闭，下次启动可能要做恢复。如果没得选，结束进程之后启动时不带--innodb-force-recovery也多半能正常起来，稍后我会讲遇到恢复状态时的处理。
3. skip-grant-tables 方式：最常用的重置路线
这是最通用的方案，适用于各种安装方式。思路一句话：让 MySQL 跳过权限验证启动，登录后直接改密码。
3.1 以跳过授权表模式启动 MySQL
确认服务已经停止后，打开管理员命令行窗口，进入 MySQL 的 bin 目录：
cd C:\Program Files\MySQL\MySQL Server 8.0\bin然后执行启动命令：
mysqld --console --skip-grant-tables --shared-memory这里解释一下参数的含义：
--console：把日志输出到当前命令行窗口，方便看到启动过程。--skip-grant-tables：核心参数，让 MySQL 启动时跳过权限表的加载，相当于所有权限校验全部失效。--shared-memory：Windows 专用参数，允许本地客户端通过共享内存连接。MySQL 8.0 中如果不带这个参数，后面的mysql -u root可能会连不上。
需要多说一句：这个命令执行后，当前窗口会被 mysqld 的输出“占住”。这是正常的，不要关掉这个窗口，否则服务会跟着退出。正确做法是另外开一个新窗口去执行连接命令。
如果你用的是集成环境（比如 XAMPP），启动命令略有不同，通常类似：
mysqld --defaults-file=C:\xampp\mysql\bin\my.ini --skip-grant-tables总之核心就是--skip-grant-tables，其他参数按实际环境调整。
3.2 登录 MySQL 并逐版本重置密码
重新开一个管理员命令行窗口，执行：
mysql -u root这个命令不要求输密码，因为此时权限校验已经关了。执行成功后会进入 mysql 命令行提示符，看到类似这样的内容：
Welcome to the MySQL monitor... Type 'help;' or '\h' for help.接下来是最关键的一步。根据版本选择对应的重置语句。
MySQL 5.7 及以前：
USE mysql; UPDATE user SET authentication_string=PASSWORD('NewPassword123!') WHERE User='root'; FLUSH PRIVILEGES;MySQL 5.7 里PASSWORD()函数仍然可用，墙裂建议用authentication_string字段，避免 5.7 和 8.0 的兼容问题。如果你所在的 5.7 版本比较老，authentication_string这个字段可能存在也可能不存在。不存在就改用Password字段：
UPDATE mysql.user SET Password=PASSWORD('NewPassword123!') WHERE User='root'; FLUSH PRIVILEGES;MySQL 8.0：
ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewPassword123!'; FLUSH PRIVILEGES;或者用 UPDATE 方式，在 8.0 里直接改 authentication_string 需要先算好哈希值，比较麻烦，所以优先推荐 ALTER USER。
等一下，这里有个很容易翻车的细节。MySQL 8.0 在skip-grant-tables模式下直接执行ALTER USER，有时候会报错Access denied或提示root@localhost 不存在。这不是命令写错了，而是 8.0 在跳过授权表模式下的行为与 5.7 不同。遇到这种情况，可以先执行：
FLUSH PRIVILEGES;然后再执行ALTER USER。FLUSH PRIVILEGES会让 MySQL 重新加载权限表，相当于在跳过模式下先把权限系统“唤醒”一下。首次登录时是跳过校验的，但执行 FLUSH 后，当前已有连接仍保持免密状态，不过权限表的更新会生效，这样ALTER USER一般就能执行了。
3.3 为什么必须执行 FLUSH PRIVILEGES
很多新手改了密码之后，重新启动 MySQL，结果发现密码还是不对，或者用户名能被识别但密码验证始终失败。最常见的原因就是没执行FLUSH PRIVILEGES。
FLUSH PRIVILEGES的作用是把内存中的权限信息重新加载一遍。MySQL 正常运行时会缓存一份权限数据，平时用户修改权限时不需要重启就会生效，靠的就是它。但在skip-grant-tables模式下，权限系统整体是“冻结”的，你改了表里的数据，如果不刷新，内存里依然是旧状态。重启服务后倒是会重新加载表数据，但为了避免各种不可预期的行为，执行完 UPDATE 或 ALTER USER 后立刻执行一次FLUSH PRIVILEGES是最稳的做法。
3.4 收尾：关闭跳过模式，验证新密码
重置语句执行完后，先不要急着关窗口。按下面步骤收尾：
- 在 mysql 命令行里执行
EXIT;退出。 - 回到第一个窗口（那个被 mysqld 日志占着的窗口），按
Ctrl + C或直接关闭该窗口，终止特殊模式下的 mysqld 进程。 - 确认没有残留进程。执行
tasklist | findstr mysqld，如果有输出，用taskkill /F /IM mysqld.exe强制结束。 - 重新启动 MySQL 服务：
net start mysql（或者你之前查到的真实服务名。）
- 验证登录：
mysql -u root -p输入你刚设置的新密码。如果出现欢迎信息，重置完成。业务应用也要同步验证一下能否连上，这一步别省。
整个流程在纯命令行下走完，看似繁琐，但实际熟练之后五分钟就能搞定。下面这张表是流程的速查版本：
| 步骤 | 命令/操作 | 作用 |
|---|---|---|
| 1 | net stop mysql | 停止现有服务 |
| 2 | mysqld --console --skip-grant-tables --shared-memory | 跳过权限校验启动 |
| 3 | 另开窗口mysql -u root | 免密登录 |
| 4 | 按版本执行 UPDATE / ALTER USER | 重置密码 |
| 5 | FLUSH PRIVILEGES | 刷新权限缓存 |
| 6 | 退出并终止特殊进程 | 恢复常规模式 |
| 7 | net start mysql | 正常启动服务 |
| 8 | mysql -u root -p输入新密码 | 验证 |
4. 替代方案：用 init-file 初始化文件重置
skip-grant-tables 虽然常用，但有一个小风险：在跳过授权的模式下，如果操作失误，有可能撞坏权限表或留下残留文件。而且有些 MySQL 发行版（特别是从 8.x 某些小版本开始）对--skip-grant-tables的处理不够友好，会出现意料之外的报错。这时候，--init-file就是一条更干净的备选路线。
4.1 这个方案适合什么样的场景
init-file 的本质是：MySQL 在启动时，自动执行指定文件里的 SQL 语句。因为它是在服务正式启动的过程中执行的，执行时机比 skip-grant-tables 更接近正常运行状态，所以权限表是完全可写的，ALTER USER一般不会报错。
这个方案特别适合：
- MySQL 8.0 环境中 skip-grant-tables 模式工作不正常的情况。
- 你对命令行操作不熟悉，希望以更接近“正常启动”的方式重置。
- 需要修改多个账号密码或执行多条 SQL 的复杂场景。
它的代价也很明显：你必须知道自己当前密码，才能在执行前把配置文件里的启动方式切回来。不对，这里我说错了——init-file 方案不需要知道旧密码，它和 skip-grant-tables 一样，都是在服务启动时执行 SQL，执行完就能把密码改掉。真正需要注意的，反而是执行完以后要立刻删除初始化文件里的明文密码，同时把启动参数降回来。
4.2 操作步骤：写 SQL、指定文件、启动
以管理员身份打开命令行窗口，先停掉 MySQL 服务：
net stop mysql然后找一个安全的位置创建 SQL 文件，例如C:\mysql-init.txt。使用记事本或代码编辑器创建，内容如下。注意文件编码建议用 UTF-8 无 BOM，否则某些版本可能中文乱码或解析异常。
对于 MySQL 5.7：
ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewPassword123!';对于 MySQL 8.0 也一样：
ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewPassword123!';如果ALTER USER因为某些原因报错，可以改成 UPDATE 方式：
UPDATE mysql.user SET authentication_string='' WHERE User='root'; FLUSH PRIVILEGES;注意，UPDATE 方式是先把密码清空，相当于变成免密状态，然后再用正常模式启动后设置新密码。这种做法多一步，但兼容性最好。清空之后，用正常方式启动服务，执行mysql -u root直接登录（不需要密码），然后执行：
ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewPassword123!';这样就完成了设置。
接下来回到命令行，在 bin 目录下执行：
mysqld --console --init-file=C:/mysql-init.txt注意路径中用的是正斜杠/，反斜杠\在解析时可能被当作转义符，导致路径无效。如果你习惯用反斜杠，需要写成C:\\mysql-init.txt，但为了少踩坑，直接用正斜杠最省事。
正常启动后，可以先另开窗口执行mysql -u root -p尝试用新密码登录。确认成功后，回到原命令行窗口终止 mysqld 进程，然后删除C:\mysql-init.txt文件。
回到常规模式启动服务：
net start mysql再验证一次登录。
4.3 两种方案怎么选
从成功率来说，skip-grant-tables 覆盖面更广，资料也更多。init-file 的优势在于更贴近“标准启动”流程，在 8.0 上遇到 ALTER USER 权限异常的机率低一些。我个人建议：
- 第一次重置：用 skip-grant-tables，并严格按照第 3 节的顺序，熟悉整个流程。
- 遇到 8.0 的 ALTER USER 报错：不要硬啃 skip 模式，直接切 init-file 方案，五分钟解决。
- 需要批量改多个账号：init-file 更合适，一个文件写多条 SQL，启动一次全部执行。
下表是两者的对比：
| 维度 | skip-grant-tables | init-file |
|---|---|---|
| 适用版本 | 5.x、8.x | 5.x、8.x |
| 核心机制 | 跳过权限校验，手动改表 | 启动时自动执行 SQL |
| 操作复杂度 | 略高，需多窗口切换 | 低，写一条 SQL 即可 |
| 遇到 ALTER USER 权限异常的概率 | 相对高（尤其 8.0） | 低 |
| 是否修改配置文件 | 可临时添加参数，也可不修改 | 需在启动命令中指定文件 |
| 安全性 | 临时暴露免密入口 | 明文密码写在临时文件，用后需即删 |
5. 重置后的安全加固与权限审查
密码重置完成，不代表事情做完了。恰恰相反，往往忘记密码这件事本身就是一个信号：这台 MySQL 的账号管理和安全配置可能存在缺口。我有一次帮人重置完密码后，顺手查了一下账号列表，发现里面躺着一个很少使用的测试账号，密码竟然是最原始的123456，而且有远程登录权限。这种隐患比“忘记密码”本身更值得警惕。
5.1 立刻要做的三件事
重置完成后，按顺序做这三件事，每一样都简单，但每一样都能避免后续麻烦。
第一，验证应用的连接配置。如果这台 MySQL 上跑着业务系统，一定会有一个连接字符串或配置文件，里面写的是旧密码。密码重置后，这条配置必须同步更新，否则业务会连不上。具体位置因应用而异，常见的有application.yml、.env、config.php等。改完之后重启应用，确认业务恢复。
第二，检查 root 账号的主机限制。MySQL 的账号由“用户名 + 主机”唯一确定。你重置的只是'root'@'localhost'，如果之前有人建过'root'@'%'或'root'@'192.168.%，这些账号的密码仍然没变，风险依旧存在。执行下面这条 SQL，把所有 root 账号列出来：
SELECT user, host, authentication_string FROM mysql.user WHERE user='root';如果发现host是%或具体网段，且非必要，建议直接删除：
DROP USER 'root'@'%';或者给它也设上一个强密码：
ALTER USER 'root'@'%' IDENTIFIED BY 'AnotherStrongPassword!';第三，检查匿名账号。MySQL 默认装完后可能有一个空用户名的匿名账号，这同样是个安全隐患。执行：
SELECT user, host FROM mysql.user WHERE user='';有输出就删掉：
DROP USER ''@'localhost';5.2 把密码设成一个“记得住”的强密码
“记得住”和“强”听起来矛盾，但实际操作中完全能兼顾。我见过不少人重置完密码以后，为了让自己“记得住”，又设回了简单密码，比如root123、123456、admin888——这等于把刚才做的工作全部白费。
更好的做法是使用密码管理器，把强密码存在本地或私有保管库里。Windows 上很多密码管理器工具支持自动填充和团队共享，密码本身根本不需要人脑去记。如果团队习惯把密码写在文档里，那就确保文档放在受控的位置，权限不要对外开放。
如果非要个人记忆，我常用的一个技巧是选一句只有自己知道的短语，取首字母加特殊符号，例如“我在2020年买过一只橘猫”转成Wz2020nmg1zjM!。强度还过得去，也不容易忘。
5.3 顺手备份 user 表
重置密码本质上是一次对 mysql.user 表的修改。虽然不是破坏性操作，但如果中途手滑，比如把 User 字段写错了，可能导致 root 账号“消失”或权限异常。所以在切换到 skip-grant-tables 之前，有条件的话先备份整个 mysql 库的表数据。操作很简单。
在停服务之前，如果 MySQL 还能以正常方式连接（哪怕你不知道 root 密码，也可以通过其他账号连接），执行：
mysqldump -u 账号 -p mysql user > C:\mysql_user_backup.sql如果压根无法登录，那备份就无从谈起，只能跳过这步。之后所有操作都保持谨慎，至少不要同时执行多个不确定的 SQL。
另外，重置流程中会用到 mysqld 的特殊启动方式，这个过程生成的日志文件可能会留在数据目录里。比如 Windows 下可能出现一个额外的*err文件。等密码重置成功、服务正常启动后，把临时加的参数去掉，再清理掉这些临时日志。
6. 高频踩坑与排查链路
重置 MySQL 密码的流程本身不复杂，但实际执行中，各种意外状况远比流程步骤多。这里把我过去半年在处理类似问题过程中，遇见的高频故障和排查思路如实写出来。如果你哪一步卡住了，建议按照顺序对照排查。
6.1 服务无法停止或重启失败
net stop mysql提示“服务没有响应”，这种情况多半是当前有长连接或事务没释放。建议不要反复点击重启，可以直接taskkill /F /IM mysqld.exe。强制结束后，再启动时如果提示如下信息：
InnoDB: Starting an implied transaction recovery...这说明 InnoDB 正在做崩溃恢复，属正常流程，等待恢复完成即可。
如果恢复过程卡住，比如在某个日志文件上反复横跳，一般可以加上--innodb-force-recovery=1启动。这个参数不是用来修密码的，而是让 InnoDB 跳过某些损坏页。密码重置完成后正常增量备份数据，再想办法重建表。说实话，我在真实场景里没遇到过必须用到它的重置案例，但知道它的存在总能救命。
6.2 skip-grant-tables 模式下 ALTER USER 报 Access denied
在第 3.3 节提到过，这是 MySQL 8.0 的常见坑。具体报错类似：
ERROR 1290 (HY000): The MySQL server is running with the --skip-grant-tables option so it cannot execute this statement这个提示其实不是密码问题，而是当前模式限制了改写权限。解决办法很简单，执行FLUSH PRIVILEGES;后再试ALTER USER。如果还不行，那就直接走第 4 节的 init-file 方案，一条路走到黑不如换条路。
另外，某些 8.0 的小版本，在 skip-grant-tables 下执行USE mysql; UPDATE user ...也会报“无法更新”，原因同样是需要先刷新权限。遇到这类报错，可以不慌，按提示操作即可。
6.3 配置文件干扰：my.ini 里的不速之客
有些人会在 my.ini 的[mysqld]段里写过特殊配置，比如强制只允许本地连接、指定 socket、启用某些插件等。这些配置平时没问题，但在特殊启动模式下可能造成意料之外的行为。
举个真实例子：一台 Windows 服务器同时装了 MySQL 5.7 和 8.0，两个版本共用了部分数据目录配置，结果用 8.0 的 mysqld 去启动时，读到了 5.7 的 datadir，导致根本无法正常连接。这个问题的根源在于启动命令没有指定正确的 defaults-file。解决方案就是每次启动时用--defaults-file显式指向目标配置：
mysqld --defaults-file=C:\ProgramData\MySQL\MySQL Server 8.0\my.ini --skip-grant-tables --console另外，如果 my.ini 里曾经设置过skip-grant-tables（有些排查故障的临时配置忘了删），正常启动服务时也会进入免密状态。这很危险。所以重置完成后，一定要回头检查配置文件，确认skip-grant-tables这行已经从 my.ini 中消失。
6.4 登录时提示 root@localhost 密码错误，但密码刚重置过
这属于重置成功后去验证，却发现怎么都不对的情形。常见原因有三个：
我用ALTER USER设置了密码，但没有执行FLUSH PRIVILEGES，内存中的权限缓存依然是旧值。解决办法：用旧密码（如果还记得）登录，或者重新走一遍流程，补上FLUSH PRIVILEGES。
服务没有真正重启。重置后用net start mysql只是从停止状态启动，如果之前特殊模式的 mysqld 进程没有完全退出，两个实例可能同时抢占 3306 端口，新连上去的可能还是旧的、免密的实例。排查方法：tasklist | findstr mysqld，看进程数量。多余的直接taskkill。
连接时参数不对。工具里连接地址写的是 host 为localhost，但 MySQL 用户表里只认127.0.0.1。其实都一样，只要不写错跳数就行。真正需要注意的是某些客户端用了mysql_native_password插件连接，而 8.0 默认插件是caching_sha2_password，也会报密码错误。这种情况不是重置没成功，而是插件不匹配，需要在服务端调整用户插件或客户端升级驱动。
6.5 特殊启动后端口占用的排查链路
端口被占用是 Windows 下的经典问题。特殊模式启动 mysqld 时，如果原来的服务进程还活着，或者另一个 MySQL 实例在跑，3306 端口就会被占用，新实例起不来。
排查方法：以管理员身份执行netstat -ano | findstr 3306，看最后一列的 PID，去任务管理器里找对应的进程。如果是 mysqld，直接结束它；如果是别的程序，那就换端口，比如用--port=3307启动临时实例，操作完成后再改回来。
这条路走通之后，你基本已经具备独立处理 Windows 下 MySQL 密码重置问题的能力。在真实项目中，把这个流程文档化保存一份，团队里其他人再遇到同类问题，直接照着执行，能省下大量排查时间。
