数据库对象导出其实没那么难，轻松备份随时搞定不用慌

（来源：某技术社区论坛一篇名为《记一次手滑删库后的血泪教训：我是如何用导出备份拯救自己的》的分享帖）

数据库对象导出其实没那么难,轻松备份随时搞定不用慌，这话可不是我瞎说的，是我自己真金白银买来的教训，去年夏天，我在公司测试环境里折腾一个功能，本来想删掉几条没用的测试数据，结果一个手滑，条件没写对，直接把一张挺重要的用户配置表给清空了，当时我脑子就“嗡”的一声，汗立马就下来了，那会儿我才工作没多久，心想这下完蛋了，要是恢复不了，耽误了项目进度，估计就得卷铺盖走人了。

我强装镇定,赶紧去找我们组的老大，结果老大不紧不慢地问我：“昨天的备份导出了吗？”我这才想起来，公司规定每天下班前要对重要的表做一次导出备份，我赶紧跑回工位，找到昨天导出的那个SQL文件，手抖着打开，找到对应那张表的创建语句和数据插入语句，执行了一下，看着数据一行行地重新灌进表里，我那颗快跳到嗓子眼的心才算咽回肚子里，从那以后，我再也不敢小看数据库导出备份这件事了，而且我发现，这东西真的不像我想的那么复杂。

（来源：同上分享帖后续内容及笔者个人实践总结）

其实所谓的导出数据库对象,说白了就是给数据库里的东西拍个“快照”，然后把这张“照片”存成一个文件，这个文件里，会清清楚楚地记着你的表结构是怎么建的、里面有什么数据、还有那些存储过程、函数什么的代码，万一哪天你操作失误，或者服务器出问题了，就能拿着这个“快照”文件，把数据库恢复到拍照时的那个状态。

具体怎么做呢？根本不用记那些复杂的命令，现在常用的数据库管理工具，比如Navicat、DBeaver，或者MySQL自带的Workbench，都有很简单的图形化操作，你基本只需要点几下鼠标：先连上你的数据库，然后在左边找到你想备份的那个数据库或者某几张具体的表，右键点击，菜单里肯定有一个选项叫“导出”或者“Dump”、“Backup”之类的，点进去之后，通常会让你选导出的格式，一般就选SQL就行，这样导出来的文件是文本格式，你用记事本都能打开看，接着选择一下文件要保存在你电脑的哪个位置，最后点“开始”或者“确定”，工具就自动帮你把所有的东西都打包到那个文件里了，整个过程，快的话一两分钟就搞定了，跟你复制粘贴一个文件差不多简单。

（来源：某博客文章《小步快跑：谈谈日常开发中的数据库版本化管理》）

你可能觉得,我这数据又不是天天变，有必要这么频繁地导出吗？太有必要了，我把我的经验总结成了几个场景，你看看是不是这么回事：

第一,就是在你打算对数据库结构做任何修改之前，比如你想给某个表增加一个字段，或者修改字段的类型，别急着动手，先右键把这个表的结构和数据导出一份，这就好比是你动手装修房子之前，先给原来的布局拍个照，万一你新加的字段出了问题，或者发现修改不对，立马就能看着“照片”把它恢复原样。

第二,就是在你准备运行一个不确定后果的SQL脚本时，特别是那种涉及到大量数据更新或者删除的脚本，哪怕你在测试环境跑，也最好先导出一份，测试环境的数据虽然不重要，但也是你调试的基础啊，一下子全没了也挺耽误事的。

第三,定期做个全库的备份，这个不用天天做，可以每周或者每半个月做一次，相当于给你整个数据库项目立一个里程碑，以后万一出了什么大问题，最差也能回到这个里程碑的状态，总比从头开始强。

（来源：个人实践及与同行交流）

养成导出备份的习惯,最大的好处就是让你心里有底，干活不慌，我现在每次要执行一些有风险的操作时，都会下意识地先导出一份备份文件放在旁边，这个动作已经成了我的肌肉记忆，这样做之后，我再也没有经历过第一次那种“魂飞魄散”的感觉了，因为我知道，哪怕我这手再滑，点错了按钮，后面还有个“后悔药”等着我呢。

这个导出的SQL文件,你不仅可以用来恢复，还可以用来迁移，比如你想把数据库从你本地的电脑搬到服务器上，或者从一台服务器搬到另一台服务器，用这个导出文件就特别方便，在新的数据库里一执行，表、数据、程序就全都过去了。

所以你看,数据库导出备份这件事，真的没什么技术门槛，它更像是一种良好的工作习惯，一种对自己工作负责的态度，它用的工具是现成的，操作是傻瓜式的，关键就在于你愿不愿意花那一两分钟的时间去点几下鼠标，别等到真的丢了数据，追悔莫及的时候才想起来它的重要性，从现在开始，就试着把你正在操作的那个最重要的表导出一份吧，把它存到电脑一个固定的文件夹里，迈出这第一步，你就已经比别人安全了一大步，轻松备份，真的可以随时搞定不用慌。