MySQL事件调度器不能执行mysqldump等系统命令，仅支持SQL语句，无法完成文件写入、压缩、清理等备份必需操作，且备份路径不可控、缺乏安全与可靠性保障。
直接用 cron + mysqldump 是最稳定、最可控的方式，Navicat 或 MySQL 事件调度器都不适合作为生产环境的主力备份方案。
为什么不用 MySQL 的 EVENT 调度器做自动备份
MySQL 的 event_scheduler 只能执行 SQL 语句，无法调用系统命令（比如 mysqldump、gzip、find），也不能写文件到指定路径。你看到的那些“CREATE EVENT ... mysqldump”脚本实际是伪代码，根本跑不起来——mysqldump 是外部命令，不是 SQL 函数。
常见错误现象：ERROR 1064 (42000): You have an error in your SQL syntax 或 ERROR 1370 (42000): execute command access denied。
- 即使硬塞进存储过程，也受限于 MySQL 用户权限模型，无法访问文件系统
- 备份文件生成在 MySQL 服务进程的工作目录（通常是
/var/lib/mysql），不可控且不安全 - 没有压缩、过期清理、多库区分等实用能力
Linux 下用 cron + shell 脚本的实操要点
关键不是“能不能跑”，而是“跑得稳、留得住、查得着”。一个能用的脚本必须包含四件事：认证安全、时间戳命名、压缩、自动清理。
推荐做法：
- 不要在脚本里写明文密码，改用
~/.my.cnf（权限必须是600） - 用
--single-transaction（InnoDB）或--lock-tables=false（MyISAM）减少锁影响 - 文件名带完整时间戳，例如
mydb_20260702_020001.sql.gz，避免覆盖 -
find清理时用-mtime +7，不是-daystart，否则可能误删当天文件
示例片段（注意变量引用和引号）：
#!/bin/bash
BACKUP_DIR="/backup/mysql"
DATE=$(date +\%Y\%m\%d_\%H\%M\%S)
DATABASE="myapp"
mysqldump --defaults-extra-file=~/.my.cnf \
--single-transaction \
--routines \
--triggers \
"$DATABASE" | gzip > "$BACKUP_DIR/${DATABASE}_${DATE}.sql.gz"
Windows 上用 Task Scheduler 跑 .bat 的坑
Windows 的任务计划程序默认以“无桌面交互”方式运行，导致 mysqldump 报错：mysql: [Warning] Using a password on the command line interface can be insecure. 甚至直接卡住——这不是警告，是权限/环境变量缺失的真实报错。
必须处理的点：
- 把
mysqldump.exe所在目录加进系统PATH，或在脚本里写绝对路径，例如"C:\Program Files\MySQL\MySQL Server 8.0\bin\mysqldump.exe" - 用
--defaults-extra-file指向一个本地my.cnf文件（注意 Windows 路径反斜杠要转义或用正斜杠） - 在任务属性 → “常规”选项卡里勾选“不管用户是否登录都要运行”，并启用“使用最高权限运行”
- 日志输出重定向要明确，比如
> D:\backup\log\backup_%date:~-4,4%%date:~-10,2%%date:~-7,2%.log 2>&1
备份后必须验证的三件事
自动备份最大的风险不是失败，而是“看起来成功了，其实没备份上”。每天早上第一件事不是看日志，而是检查三样东西：
- 最新备份文件大小是否 > 1KB（空文件或权限错误常导致 0 字节）
- 解压后首行是否含
CREATE DATABASE或CREATE TABLE（而不是一堆Warning或Access denied） -
ls -la /backup/mysql看文件属主是不是运行脚本的用户，不是root就可能后续清理失败
真正麻烦的永远不是怎么设定时任务，而是没人定期翻备份目录确认文件真实存在且可读——这一步没法自动化，只能靠人盯。
