mysqldump 必须加 --single-transaction 避免锁表，搭配 --skip-lock-tables；php 调用需检查 exec 是否禁用；清理备份应按文件名时间戳而非修改时间；备份后须校验完整性，如 md5 和“dump completed”标记。
mysqldump 命令必须加 --single-transaction 才能避免锁表
线上 MySQL 备份最常踩的坑，就是直接跑 mysqldump 导致写入阻塞。InnoDB 表默认不加事务快照的话，mysqldump 会隐式执行 FLUSH TABLES WITH READ LOCK，一卡就是几分钟——尤其大表或高并发场景。
正确做法是显式启用一致性快照：
-
--single-transaction：对 InnoDB 表生效，全程不锁表，靠 MVCC 保证备份一致性 - 必须搭配
--skip-lock-tables（否则--single-transaction可能被忽略） - 如果库中混有 MyISAM 表，该参数无效，得改用
--lock-all-tables，但要接受短时锁表
示例命令：
mysqldump -u root -p --single-transaction --skip-lock-tables --routines --triggers mydb > /backup/mydb_$(date +\%Y\%m\%d_\%H\%M).sql
PHP 调用 shell 命令前，务必检查 exec 是否被禁用
很多生产环境 PHP 配置里禁了 exec、shell_exec 等函数，直接写 exec('mysqldump ...') 会静默失败，返回空字符串，日志里也不报错。
立即学习“PHP免费学习笔记（深入）”；
验证和兜底建议：
- 先运行
var_dump(function_exists('exec'))和var_dump(ini_get('disable_functions')) - 若被禁，改用
system()或passthru()（仍需确认是否在禁用列表） - 更稳妥的方式是把备份逻辑拆出去，用系统 cron 调用独立 shell 脚本，PHP 只负责触发通知或记录状态
- 无论如何，都要捕获
$output和$return_var：$cmd = "mysqldump ... 2>&1";<br>exec($cmd, $output, $return_var);<br>if ($return_var !== 0) { error_log("Backup failed: " . implode("\n", $output)); }
自动清理旧备份不能只靠 find -mtime +7
按天删除容易误删：比如备份脚本凌晨 2 点跑，但某天因磁盘满失败了，后续连续 3 天没生成新文件，-mtime +7 就会把 6 天前的也删掉，只剩最新一份——容灾能力归零。
更可靠的清理策略：
- 用
find按文件名时间戳过滤，而非修改时间：find /backup -name "mydb_????????_??.sql" -not -newermt "$(date -d '7 days ago' +\%Y\%m\%d_\%H\%M)" -delete - 保留至少 5 份，再加一条兜底：
ls -t /backup/mydb_*.sql | tail -n +6 | xargs -r rm - 清理前先
df -h /backup检查剩余空间，低于 20% 就发告警，暂停备份并人工介入
备份文件必须校验完整性，光看大小没用
网络中断、磁盘写满、mysqldump 进程被 kill，都可能导致 SQL 文件截断——开头是 CREATE TABLE，结尾突然没了 INSERT，文件大小看着正常，还原时才报错。
简单有效的校验方式：
- 生成时追加 MD5：
mysqldump ... | tee /backup/xxx.sql | md5sum > /backup/xxx.sql.md5 - 还原前检查是否含关键结束标记：
tail -n 20 /backup/xxx.sql | grep -q "Dump completed"（mysqldump默认会在末尾输出这行） - 抽样解压（如果用了 gzip）+ 检查首尾：
gzip -t backup.sql.gz && zcat backup.sql.gz | head -n 5 | grep -q "CREATE DATABASE"
容灾不是“有备份就行”，是“能还原且数据完整”。校验步骤漏掉一次，恢复时就可能多花三小时找原因。
