计划任务备份 MySQL 的坑：单表与全库的选择

发布时间:2026-10-14 09:54

## 案例 某个内容型站点，数据库里文章表几百万行，配置类小表十几个。备份脚本每天凌晨 mysqldump 全库导出，稳定跑了半年。某天运营误删了配置表里的支付参数，需要恢复。运维拿了最近的全库备份，在测试机导入整个库花了一个多小时，恢复后业务方才发现：备份之后到误删之前的几个小时，文章表的新增数据全被覆盖丢失了。一次看似顺利的恢复，实际造成了一次二次数据事故。 ## 根因分析 问题出在恢复粒度与备份策略的错配。全库备份解决的是"整库损毁"场景，恢复时只能整库回到备份时刻，备份与故障之间的增量一律蒸发。而日常最高频的恢复需求恰恰是小范围恢复：误删一张配置表、误清一个字段，需要的只是单表回到某个时刻，且尽量不影响其他表的最新数据。全量导出对这类需求既笨重又危险，一个多小时的导入窗口里，业务还在写入，覆盖式恢复的代价被进一步放大。 ## 修复过程 团队改造了三层。第一层，备份粒度拆分：配置类小表每天单独导出，文章类大表全量加增量配合，恢复配置表只导入单表文件，分钟级完成，影响面被限制在单表内。第二层，导出参数标准化，把选项显式写进命令而不是依赖默认： ```bash mysqldump --single-transaction --routines --triggers mydb > mydb_$(date +%F).sql ``` --single-transaction 保证一致性快照，--routines --triggers 带上存储过程与触发器，之前全库导出竟然没带存储过程，也是这次盘点出来的隐患。第三层，建立恢复预案：把常见故障场景与对应的恢复步骤写成手册，标注每种场景用哪份备份、影响哪些数据、需要多久停写。 ## 复盘要点 备份的价值由恢复定义，恢复演练要覆盖"单表误删"这种高频场景，不能只演练整库重建。全库与单表不是二选一，是组合：全库保底、热点小表加密备份、大表配合增量，恢复时间目标决定备份频率。备份文件的命名带上库与表名，检索要快，恢复时拿错文件比没备份更糟。在顺云的云服务器上，把这套分层备份与快照策略配合使用，磁盘级快照兜整机的底，逻辑备份做精细恢复，两层各司其职。