不加--single-transaction的mysqldump备份不可信，因其默认触发FLUSH TABLES WITH READ LOCK导致写入阻塞，且InnoDB表在并发写入时导出数据来自多个时间点，造成跨事务不一致；该参数通过REPEATABLE READ隔离级别建立一致性快照，全程不锁表，但仅对InnoDB有效，MyISAM表需改用--lock-all-tables。
不加 --single-transaction 的 mysqldump 备份不可信，恢复后数据大概率跨事务不一致——这不是“可能出错”，而是设计上就无法保证一致性。
为什么 mysqldump 必须带 --single-transaction
InnoDB 表在并发写入时，不加该参数会导致导出的数据来自多个不同时间点的快照。比如用户表更新了，但关联的日志表还没刷进去，备份文件里就出现逻辑断层。加了 --single-transaction 后，mysqldump 会自动开启一致性读（REPEATABLE READ 隔离级别），全程不锁表，只对当前事务可见的数据做快照。
注意：--single-transaction 对 MyISAM 无效。如果库中混用 MyISAM（老系统常见），先查引擎：
SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db';
若存在 MyISAM 表，必须改用 --lock-all-tables，否则备份必然损坏。
~/.my.cnf 权限必须是 600，且路径必须匹配执行用户
明文密码写进脚本或命令行，等于把钥匙贴在保险柜上——ps aux、shell 历史、日志轮转都可能泄露。唯一安全方式是用 MySQL 官方支持的配置文件：
- 内容必须是
[client]段（不是[mysqldump]，后者不生效） - 文件路径必须是 crontab 执行用户的家目录：root 运行就放
/root/.my.cnf，普通用户就放/home/username/.my.cnf - 权限必须执行
chmod 600 ~/.my.cnf，否则 MySQL 客户端直接拒绝读取
脚本中调用时显式指定更稳妥：
mysqldump --defaults-extra-file=/root/.my.cnf --single-transaction your_db
crontab 执行失败？90% 是环境变量和 PATH 问题
手动运行脚本成功，放进 crontab 就静默失败——根本原因在于 cron 不加载 ~/.bashrc 或 /etc/profile，默认 $PATH 极简（通常只有 /usr/bin:/bin），而 mysqldump 可能装在 /usr/local/mysql/bin。
解决方法只有两个，且必须同时做：
- 在脚本开头硬编码
PATH：export PATH="/usr/local/mysql/bin:/usr/bin:/bin" - 所有命令用绝对路径：
/usr/local/mysql/bin/mysqldump而不是只写mysqldump - 测试 cron 环境是否生效：
sudo -u root /bin/bash -c 'mysqldump --defaults-extra-file=/root/.my.cnf -e "SELECT 1"'
备份脚本里必须校验三件事：退出码、文件大小、时间戳命名
crontab 不报错 ≠ 备份成功。常见静默失败场景：磁盘满导致 mysqldump 写入中断、网络闪断、GTID 参数缺失引发导出提前终止。脚本里必须做基础校验：
- 检查
mysqldump退出码：if [ $? -ne 0 ]; then echo "dump failed" >&2; exit 1; fi - 检查生成文件大小：
if [ ! -s "$BACKUP_FILE" ]; then echo "empty backup file" >&2; exit 1; fi - 文件名必须含时间戳（如
db_$(date +\%Y\%m\%d_\%H\%M).sql.gz），否则无法区分新旧、无法按天清理
最容易被忽略的是 GTID 参数：MySQL 5.7.6+ 默认开启 GTID，不加 --set-gtid-purged=OFF，备份文件里会包含 SET @@GLOBAL.GTID_PURGED，恢复时大概率触发 ERROR 1840 (HY000)。
