能跑通的自动备份脚本关键在三处：mysqldump必须加--single-transaction确保InnoDB一致性快照，crontab需显式指定--defaults-extra-file路径且~/.my.cnf权限为600，脚本必须检查mysqldump退出码并校验gzip文件。

开门见山，一个真正能稳定运行的MySQL自动备份脚本，其核心往往不在于功能写得多么花哨，而在于能否精准把握三个关键点：「mysqldump的参数是否到位」、「crontab的环境能否正确读取配置」以及「脚本是否严格检查了每一步的执行结果」。这三者缺一不可，任何一个环节的疏忽，都可能导致备份在无人察觉的情况下静默失败。

mysqldump 必须加 --single-transaction 才算安全

这里有个常见的误区：以为执行了mysqldump就能得到一份完整的数据快照。实际上，如果不加--single-transaction参数，在备份InnoDB表的过程中，若遇到写入操作，导出的数据就可能出现跨事务不一致的情况。想象一下，用户表更新了，但关联的订单明细却没跟上，用这样的备份恢复，数据逻辑就彻底断裂了。

• --single-transaction这个参数的作用，是为整个备份过程开启一个一致性快照，全程不锁表，但请注意，它只对InnoDB引擎有效。
• 如果你的数据库是混合引擎，比如还包含一些遗留的MyISAM表，最好先确认一下：SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db';
• 顺手把--routines（存储过程）、--triggers（触发器）、--events（事件）这几个参数也加上，否则这些数据库对象不会进入备份文件。
• 对于MySQL 5.7.6及以上版本，默认开启了GTID，备份时必须显式加上--set-gtid-purged=OFFERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty这样的报错。

crontab 脚本里不能靠 ~/.my.cnf 自动读密码

很多人在命令行测试得好好的脚本，一到crontab就失灵，问题往往出在这里。cron守护进程在执行任务时，不会加载用户shell的profile或bashrc配置文件。这意味着，脚本里写的~/.my.cnf这个路径，会被解析成cron守护进程自身用户的家目录（通常是/root）。如果你的配置文件放在其他用户目录下，它自然找不到。

• 解决方案有两种：要么在mysqldump命令中显式指定配置文件的绝对路径：mysqldump --defaults-extra-file=/root/.my.cnf --single-transaction your_db > file.sql
• 要么在脚本开头重新设置PATH环境变量，并确保所有命令都使用绝对路径：export PATH="/usr/bin:/bin:/usr/local/mysql/bin"
• 这里有一条安全红线：密码绝不能以明文形式写在脚本里。正确的做法是放在/root/.my.cnf这样的配置文件中，并且务必将其权限设置为600。文件内容格式如下：

  [client]
  user=root
  password=your_real_password

• 如何模拟cron环境进行测试？可以试试这个命令：sudo -u root /bin/bash -c 'mysqldump --defaults-extra-file=/root/.my.cnf -e "SELECT 1"'

备份脚本必须检查 mysqldump 退出码再往下走

这是另一个导致“虚假成功”的陷阱。mysqldump可能因为权限不足、连接失败或磁盘已满而执行失败，但脚本却继续运行，生成了一个空的.sql文件。后续的压缩、清理步骤照常执行，日志里可能还打印着“backup success”，实际上备份文件只是个空壳。

• 一个简单的判断逻辑就能避免这个问题：

  mysqldump --defaults-extra-file=/root/.my.cnf --single-transaction your_db | gzip > /backup/your_db_$(date +\%Y\%m\%d_\%H\%M).sql.gz
  if [ $? -ne 0 ]; then
    logger -t mysql-backup "mysqldump failed at $(date)"
    exit 1
  fi

• 压缩完成后，也建议校验一下文件完整性：gzip -t /backup/your_db_*.sql.gz，防止管道传输中途中断导致文件损坏。
• 日志记录不要只用echo输出到终端，crontab默认不会保存这些输出。使用logger -t mysql-backup将信息写入系统日志，是更可靠的做法。
• 在备份开始前，不妨加一步磁盘空间检查：df /backup | awk 'NR==2 {print $5}' | sed 's/%//' | awk '$1 > 90 {exit 1}'，如果备份目录使用率超过90%，就跳过本次备份并触发告警。

crontab 时间格式和权限最容易写错

crontab的时间表达式看似简单，却很容易踩坑。比如，2 0 * * *表示的是每月2号0点执行，而不是每天凌晨2点。再比如，0 2 * * 1是每周一2点执行，但如果你同时又写了0 2 1 * *，那么每月1号2点也会触发——因为cron的“日”和“周”字段是“或”的逻辑关系，而非“且”。

• 每天凌晨2点执行的正确写法是：0 2 * * *（顺序为：分、时、日、月、周）
• 编辑需要root权限的定时任务时，必须使用sudo crontab -e。直接使用crontab -e编辑的是当前用户的任务，很可能没有权限读取MySQL配置文件或写入/backup目录。
• 确保你的脚本第一行有正确的shebang：#!/bin/bash，并且赋予了执行权限：chmod +x /backup/mysql_backup.sh。
• 最后再强调一次：时间表达式中，尽量避免同时指定“日”和“周”字段，像0 2 1 * 1这样的写法，会导致每月1号和每周一都执行，这可能并非你的本意。

说到底，构建一个可靠的备份链路，真正的难点不在于写出几行脚本，而在于确保从mysqldump获取一致性快照，到cron使用正确的环境变量，再到最终备份文件的完整性校验，每一步都是可验证、可监控的。任何一环发生静默失效，都可能让你在需要恢复数据时，陷入无备可用的困境。