Windows任务计划无法直接巡检MySQL健康状态，必须用mysqladmin ping做连接级探测，并通过批处理脚本结合net start实现自动恢复。
Windows 任务计划程序本身不能直接“巡检”MySQL服务状态，它只能触发命令或脚本；真正的服务健康判断必须靠外部逻辑实现。你真正需要的不是“计划任务配置”，而是「一个能被计划任务调用、且能准确识别 MySQL 是否真挂了的检测脚本」。
为什么直接用 sc query 判断服务状态不可靠
sc query MySQL80 返回 STATE: RUNNING，不代表 MySQL 能响应 SQL 请求。常见失效场景包括：
- mysqld 进程卡在锁等待或 SIGSTOP 状态，SCM 仍认为它“活着”
- innodb_force_recovery=1 导致服务启动但拒绝所有连接
- 磁盘满、内存不足时 mysqld 可能僵死而不退出进程
- 端口（如
3306）被其他进程占用，服务看似运行，实则无法通信
所以单纯检查服务状态是无效的，必须做连接级探测。
用 mysqladmin ping 做轻量级可用性验证
mysqladmin 是 MySQL 自带工具，比写 Python 脚本更轻、更稳定，且不依赖额外运行时环境。它能真实模拟客户端握手流程。
推荐检测命令（需提前配置好 my.cnf 或使用 --defaults-file）：
mysqladmin --defaults-file="D:\MySQL\Server80\my.ini" ping -u root -p"your_password" 2>NUL
关键点：
Windows 桌面自动化技能，支持鼠标控制（移动/点击/拖拽/滚轮/截图）、键盘输入（文字输入/按键/组合键）、窗口管理（查找/聚焦/最大化/最小化/关闭/移动）、截图并发送文件。提供两种截图方式：Python pyautogui 截图（集成在自动化流程中）和 PowerShell + .NET 零依赖截图（支持区域截图和多显示器）。当用户需要自动化 Windows 桌面操作、控制鼠标键盘、管理窗口、执行 GUI 自动化任务、截图发送文件时使用。
- 必须用
--defaults-file指向你的my.ini，否则可能读不到basedir或认证信息 - 密码含特殊字符（如
!、&）时，整个-p"xxx"要用双引号包裹，且避免在批处理中裸写明文密码（生产环境建议用配置文件免密） - 返回码为
0表示连得上；非0（如1）表示失败，可据此触发后续动作
计划任务中调用检测并自动拉起服务
不要在任务计划里直接写复杂逻辑。把检测和恢复拆成两个独立批处理，再由任务计划调用：
1. 创建 check_mysql.bat：
@echo off
mysqladmin --defaults-file="D:\MySQL\Server80\my.ini" ping -u root -p"your_password" >NUL 2>NUL
if %ERRORLEVEL% neq 0 (
echo [%date% %time%] MySQL unreachable, restarting service...
net stop MySQL80 >NUL
timeout /t 3 /nobreak >NUL
net start MySQL80 >NUL
)
2. 在任务计划中新建基本任务：
- 触发器：每 2 分钟运行一次（避免太频繁触发 SCM 的失败计数限制）
- 操作：启动程序 →
cmd.exe，参数填/c "D:\MySQL\Scripts\check_mysql.bat" - “使用最高权限运行”必须勾选，否则
net start会失败 - “不管用户是否登录都要运行”建议勾选，确保后台持续生效
注意：net start 成功不代表 MySQL 真正就绪，它只表示 SCM 发出了启动信号。若 mysqld 启动慢（比如数据目录大、有崩溃恢复），下一轮检测前可能还没 ready，这时会重复触发重启 —— 所以建议在脚本里加 timeout /t 10 再测一次，或改用更健壮的重试逻辑。
真正容易被忽略的点
多数人卡在权限和路径上：任务计划默认以 SYSTEM 账户运行，它看不到你用户目录下的 my.ini，也读不到用户环境变量里的 PATH。所以：
-
mysqladmin必须写绝对路径，例如"D:\MySQL\Server80\bin\mysqladmin.exe" -
--defaults-file的路径必须是 SYSTEM 账户可读的本地路径（不能是映射网络驱动器或 OneDrive 同步路径） - 如果用配置文件免密（推荐），该文件权限需设为仅管理员可读，否则会被任务计划执行环境拒绝加载
