根本原因是mysqld进程在初始化阶段崩溃退出，需以管理员身份运行mysqld --console查看真实错误日志；常见原因包括datadir或log-error路径不可写、插件加载失败（如caching_sha2_password或SSL）、InnoDB文件被锁或损坏。
MySQL服务启动后立即退出，根本不是服务“没启动”，而是mysqld进程在初始化阶段崩溃退出，Windows服务管理器只来得及报一句“服务已停止”——真正原因藏在它自己写的日志里，而不是事件查看器或控制台一闪而过的提示中。
直接前台启动 mysqld 查看真实错误输出
Windows服务包装器会截断早期错误、超时强制杀进程，导致你看不到关键报错。必须绕过服务，用命令行直接运行 mysqld：
- 先以管理员身份打开 cmd，执行
sc delete MySQL（如果已注册为服务） - 进入 MySQL 的
bin目录，比如C:\Program Files\MySQL\MySQL Server 8.0\bin - 运行：
mysqld --console --skip-grant-tables --log-error-verbosity=3
这时窗口不会关闭，所有初始化日志（包括 InnoDB 打开 ibdata1 失败、SSL 插件加载失败、配置语法错误）都会实时打印出来。常见输出如：InnoDB: Unable to lock ./ibdata1 或 Plugin 'caching_sha2_password' init function returned error，这些才是真凶。
检查 my.ini 中 datadir 和 log-error 路径是否可写
MySQL 启动时需创建/写入 error log 和系统表空间文件。若路径不存在、权限不足或含中文/空格，mysqld 会静默退出。
- 打开
my.ini，确认datadir和log-error指向的目录存在且为绝对路径（如C:/mysql/data，不要用C:\Program Files\...这类带空格路径） - 右键目标目录 → “属性” → “安全” → 确保
NETWORK SERVICE或你运行服务的用户有“完全控制”权限 - 若
log-error未显式配置，MySQL 默认写到datadir下的主机名.err文件，该目录必须可写
特别注意：XAMPP 用户默认 datadir=C:\xampp\mysql\data，但若你曾手动移动过 data 目录却没同步改 my.ini，就会卡在第一步。
排查插件加载失败（尤其是 caching_sha2_password 和 SSL）
MySQL 8.0 默认启用 caching_sha2_password 认证插件，若其依赖的证书文件缺失或权限不对，mysqld 会在加载插件阶段直接退出，且不报具体插件名。
- 在
[mysqld]段开头添加：early-plugin-load = ""，这会禁用所有插件预加载，排除插件干扰 - 再配合前台启动测试，若此时能成功，说明是某个插件（常见为 SSL 或认证插件）出问题
- 恢复插件加载后，检查
ssl-ca、ssl-cert、ssl-key是否指向真实存在的 PEM 文件，或干脆注释掉 SSL 相关配置项
这个点最容易被忽略：你没动过 SSL 配置，但 Windows 更新可能重置了证书存储，或杀毒软件删了临时生成的密钥文件。
验证 InnoDB 系统表空间文件是否损坏或锁住
绝大多数“启动即停”最终都指向 InnoDB 初始化失败，典型标志是日志里出现 Operating system error number 13（拒绝访问）或 Unable to lock ./ibdata1。
- 关掉所有 MySQL 进程（包括后台残留的
mysqld.exe，用tasklist | findstr mysqld确认） - 进
datadir目录，检查ibdata1、ib_logfile0、ib_logfile1是否存在且非零字节 - 若存在但上次异常关机，可临时重命名它们（如加
.bak），让 MySQL 重建；但务必先备份整个datadir - 若文件被其他进程锁定（如杀毒软件、Windows Search），尝试暂时禁用实时防护再试
这里的关键是：不要一上来就删文件或重装，InnoDB 损坏往往只是文件锁或权限问题，而非数据逻辑损坏。
真正麻烦的从来不是“怎么重启”，而是 mysqld 在哪一行代码里决定退出——它不告诉你，除非你让它把 stdout/stderr 全打出来。日志路径、插件加载顺序、文件锁状态，三者任何一个出问题，都会让你看到那个“服务已停止”的弹窗，然后陷入无意义的重启循环。
