MySQL 8.0在Windows下无原生自启机制，需通过sc failure配置服务崩溃后的系统级自动重启策略，而非依赖脚本轮询；必须设为start= auto并正确设置actions= restart/60000等参数，配合错误日志排查真实故障原因。
MySQL 8.0 在 Windows 下没有原生的“自动重启”机制，所谓“宕机自启”本质是靠 Windows 服务自身的失败响应策略，不是 MySQL 自己决定重拉。 直接改服务属性就能生效，不需要写脚本、不推荐用 Python 轮询 —— 那种方式既绕过系统服务模型，又容易引发冲突或权限问题。
为什么 sc config 的 failure 参数才是正解
Windows 服务控制管理器（SCM）本身就支持对服务崩溃后的响应动作，MySQL 作为标准 Windows 服务，天然适配这套机制。关键不是“让它一直运行”，而是“它挂了之后怎么救”。sc failure 命令就是干这个的。
-
sc failure设置的是服务进程退出后的系统级响应，比用户层脚本更底层、更可靠 - 它不依赖第三方解释器（如 Python）、不占用额外进程、不产生日志污染
- 若 MySQL 进程因内存不足、磁盘满、配置错误等异常退出，SCM 会按你设定的动作执行，而非等待脚本下一轮检测（可能间隔几十秒）
sc failure 命令怎么写才有效
必须以管理员身份运行 CMD 或 PowerShell，且服务名要和 sc query 输出一致（通常是 MySQL80，不是 mysql 或 MySQL）：
sc failure MySQL80 reset= 86400 actions= restart/60000/restart/60000/restart/60000
这行命令含义：
-
reset= 86400：计数窗口为 24 小时（单位秒），超时后失败次数清零 -
actions= restart/60000/...：连续失败 1 次 → 等 60 秒后重启；再失败 → 再等 60 秒重启；第三次失败仍等 60 秒 —— 三个动作全写成restart/60000是最常用且稳妥的组合 - 不要写
run/...或command/...，MySQL 不支持外部命令接管启动流程
验证是否设置成功：sc qfailure MySQL80，输出中应含 Reset Period : 86400 和对应 Actions 行。
哪些情况会让 failure 策略失效
即使配置了 sc failure，MySQL 仍可能“挂了不拉”，常见原因有：
- MySQL 进程没真正退出：比如卡死在
SIGSTOP或无限等待锁，此时 SCM 认为服务“仍在运行”，不会触发 failure 动作 - my.ini 中
innodb_force_recovery> 0 或配置严重错误，导致 mysqld 启动即退出 —— failure 会反复尝试，但若每次都在 1 秒内崩溃，SCM 可能进入“服务启动被拒绝”状态（查sc queryex MySQL80看WIN32_EXIT_CODE） - datadir 权限丢失或磁盘只读：failure 动作会执行，但重启必然失败，形成死循环；需配合事件查看器（
eventvwr.msc→ Windows 日志 → 应用程序）查MySQL日志定位真实原因 - 服务被手动设为
disabled：failure 设置会被忽略，先确认sc qc MySQL80中START_TYPE是2 - AUTO_START
别碰“延迟启动”和“自动(延迟启动)”
如果服务启动类型是 DELAYED_AUTO_START（即图形界面里选的“自动(延迟启动)”），sc failure 响应大概率不触发 —— 因为 SCM 对延迟启动服务的失败判定更宽松，且首次启动失败后可能直接放弃。生产环境务必用：
sc config MySQL80 start= auto
然后再配 sc failure。两步缺一不可：先确保它“该起就起”，再确保它“挂了就拉”。
真正难的不是配参数，而是区分“服务没起来”和“服务起来了但连不上”——后者往往不是 failure 能解决的，得看 error log 里的具体报错，比如 Can't start server : Bind on TCP/IP port: Address already in use。
