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 同步路径) - 如果用配置文件免密(推荐),该文件权限需设为仅管理员可读,否则会被任务计划执行环境拒绝加载










