mysqldump + 系统计划任务是最稳定、最低侵入的MySQL自动备份方案；需显式指定PATH或mysqldump绝对路径，密码改用chmod 600的~/.my.cnf，时间戳需转义或用PowerShell生成，务必加--single-transaction等参数并做gzip和建表语句校验。
mysqldump + 系统计划任务是当前最稳定、最低侵入的 MySQL 自动备份方案。它不依赖第三方 GUI 工具，也不需要修改 MySQL 配置（如开启 event_scheduler），只要操作系统有定时能力、MySQL 服务可访问，就能跑起来。
Linux 下用 crontab 调用 shell 脚本备份
关键不是“能不能跑”，而是“跑得稳不稳、安不安全、好不好查”。常见翻车点集中在权限、路径、环境变量和密码暴露上：
-
mysqldump在 cron 里执行失败，90% 是因为PATH不一致 —— cron 默认只带极简环境，/usr/bin或/usr/local/mysql/bin很可能不在其中。解决办法：脚本开头显式声明PATH，或直接写mysqldump的绝对路径（如/usr/bin/mysqldump） - 密码明文写在脚本里？立刻停用。改用
~/.my.cnf：[client] user = backup_user password = your_secure_password host = localhost port = 3306
然后chmod 600 ~/.my.cnf。脚本里就只需写mysqldump --defaults-extra-file=~/.my.cnf your_db - 备份文件名含空格或特殊字符（如
%），date命令要加转义：$(date +\%Y\%m\%d_\%H\%M\%S)，否则 cron 解析会出错 - 别忘了加
--single-transaction（InnoDB 表适用），避免锁表；加--routines --triggers --events才能完整导出存储过程、触发器等元数据
Windows 下用任务计划程序执行 .bat 脚本
Windows 的坑更隐蔽：任务计划默认以“非交互式”方式运行，意味着它看不到你的用户环境变量，也读不到你桌面登录时加载的 PATH。结果就是：明明命令行能跑的 mysqldump，一到计划任务里就报“不是内部或外部命令”。
- 必须在任务的“操作”中指定完整路径：
"C:\Program Files\MySQL\MySQL Server 8.0\bin\mysqldump.exe"—— 注意引号不能少，路径含空格时 Windows 会直接截断 - 时间戳生成别用
%DATE%和%TIME%，它们格式随系统区域设置变（比如中文 Win10 默认是“2026/06/11”），导致文件名非法。推荐用 PowerShell 命令生成标准格式：powershell -Command "Get-Date -Format 'yyyyMMdd_HHmmss'" - 任务“常规”选项卡里务必勾选“不管用户是否登录都要运行”，并启用“不保存密码时只在运行时提供” —— 否则任务可能静默失败，连日志都不留
- 备份目录权限要提前设好：右键文件夹 → 属性 → 安全 → 给“SYSTEM”账户赋予“完全控制”，否则计划任务进程无权写入
备份脚本里必须包含的健壮性检查
没人天天盯着日志，所以脚本自己得会“喊疼”。光靠 mysqldump 成功退出码不够，得叠加业务层验证：
- 执行
mysqldump后，立刻用gzip -t检查生成的.sql.gz是否可解压 —— 避免因磁盘满、权限不足导致空文件被当成成功备份 - 用
zcat file.sql.gz | head -n 50 | grep -q "CREATE TABLE"确认压缩包里真有建表语句，不是 mysqldump 报错后输出的错误文本被 gzip 一起压进去了 - 备份完成后，把本次文件大小写进日志，并对比前一次大小：如果连续两次大小差 mysqldump 默认静默跳过不存在的库）
- 清理旧备份别只用
find ... -mtime +7—— 这个按“修改时间”算，而压缩文件的 mtime 是 gzip 写入时间，不一定等于备份逻辑时间。稳妥做法是按文件名里的日期解析，再删
SHOW TABLES 结果和原库一致、关键数据能查出来 —— 这步不做，备份就只是硬盘上一堆安慰剂。 
