运维转数据库第一年，我先补的是备份恢复

先回答一个我被问过好几次的问题：从运维转数据库，第一年先学 SQL 还是先学备份？

我自己的答案是后者。不是 SQL 不重要，是我当年在这上面栽过跟头。

我是满小满，做了四年数据库运维，从运维岗转过来。

这个号写我做过、踩过、返工过的事。技术讲到够用，专业词后面跟一句说人话的解释。

一、值班时真正让我慌的，不是 SQL 慢

运维转数据库，最容易把注意力放在 SQL 上。

觉得会写查询、能看懂执行计划，就算入门了。

我一开始也这么想。

但值班时真正让人慌的，往往不是「这条 SQL 慢」，而是：

• 数据还在不在；
• 出问题能不能退回去；
• 退回去要多久；
• 退回去以后，业务能不能接受。

前三个问题靠备份恢复和回滚方案回答，第四个问题靠你和业务提前对齐。

SQL 优化，是后面的事。

二、备份这件事，我后来只问四个问题

我不太爱背规范，后来干脆把备份拆成四个问题。每次值班前看一遍，心里会踏实一点。

前两个问题回答「有没有」，后两个回答「敢不敢用」。

这张表是我从一张 A4 纸清单慢慢改出来的，最早只有前两项。

这四项不是问一次就完了。

备份策略会变，数据量会变，人员也会变。

我一般每季度复核一次，至少确认恢复演练还在做、恢复耗时没有明显变长。

如果这四个问题里有任何一个答不上来，先别急着优化 SQL，先把备份恢复这条链路走通。

我转岗后第一个跟头，就和 SQL 无关。

领导让我整理备份策略，我以为备份就是每天导出一份，脚本跑了三天，磁盘到了 98%。

凌晨两点，我一边删备份文件，一边手抖。

师父只说了一句：「备份不是『有文件』，是『能恢复』。」

这句话听起来像常识，但真正做起来，要落到四个问题里。

三、变更前，我会准备三张纸

数据库变更不怕慢，怕的是退不回去。

我现在做变更，至少准备三张纸。

第一张：变更单。

写清楚改什么、为什么改、影响哪些库、谁确认、什么时候做。

不是走形式，是让所有人对「这次要动什么」有同一个理解。

第二张：回滚脚本。

回滚脚本要和正事一起写，不能等出事再想。

写完后在测试库跑一遍，确认能退回到变更前的状态。

回滚脚本里要包含验证 SQL，不能只写「执行某条命令」。

第三张：验证清单。

变更后看什么：会话正常吗、错误日志有新增吗、关键业务 SQL 的耗时在基线内吗、数据对得上吗。

每项写清楚「正常」的标准，不写「看一下」。

我一开始也嫌麻烦。后来发现，真出事时能救你的就是它们。

它们不能防止出事，但能让你在出事时不是凭记忆处理。

四、如果你刚转岗，可以照着这四周慢慢来

不是标准答案，是我自己走过一遍、觉得有用的顺序。

第 1 周：摸清家底

• 列出所有库、实例、负责人；
• 记录备份方式、保留天数、存放位置；
• 找到错误日志、慢日志、审计日志的路径。

第 2 周：做一次恢复演练

• 选一个测试库，按真实流程恢复；
• 记录开始、结束、卡点；
• 恢复后做行数、金额、边界数据校验。

第 3 周：补变更流程

• 找一份最近的变更单，看有没有回滚脚本；
• 没有的话，补一份；
• 在测试库把回滚脚本跑一遍。

第 4 周：写一页纸复盘

• 选一次真实故障或慢查询；
• 按「现象—假设—验证—结论」写；
• 写不出来也没关系，说明还没真正定位。

不用四周都做完。能先做一周，也比收藏一堆路线图强。

五、这个号会写什么

我会写五个方向：转行要补哪几层、换库前后踩过的坑、值班现场、小工具实测，以及女生在技术岗上的具体处境。

不会写：几天入门的承诺、命令大全、产品对比和选型推荐（首月）、客户名和系统名、没有出处的性能倍数。

六、最后，说点心里话

技术讲七分，感受讲满。

这不是说技术不重要，是说我知道自己还在路上，不想把没验证的东西讲成结论。

你们库上一次恢复演练是什么时候？

如果答不上来，也不丢人。我当年也答不上来。

评论区聊聊，不用写公司名。