干这行久了，你会发现一个扎心的真相：数据库崩了不可怕，可怕的是你压根没备份，或者备份了却恢复不了。前者是懒，后者是蠢，而mysqldump这工具，就是专门治这俩毛病的。它是MySQL自带的逻辑备份工具，原理不复杂，就是把表结构和数据用SQL语句导出来，存成一个文本文件。你哪天要恢复，再把这个文件导回去就行。听起来简单，但用得好和用得糙，差别大了去了。
先说最基本的用法，一条命令搞定：。这条命令会把整个库的结构和数据全导出来，适合中小型项目。但你得留个心眼，如果数据库里有些表是临时表或者缓存表，每次备份都带着它们，纯粹浪费时间。这时候就得用参数，把那些不重要的表跳过。我见过不少新手，备份文件动辄几个G，一问才知道，里面一半都是日志表，恢复的时候哭都来不及。
再往上走一步，你得考虑分库分表备份。一个大库动辄几十个G，全量备份一次要半小时，生产环境哪受得了。我的习惯是，核心表单独备份，普通表批量打包，再用crontab定时跑。比如每天凌晨两点，先备份用户表、订单表这种关键数据，再备份其他表。这样万一真出事了，恢复核心表用不了五分钟，剩下的表慢慢导也不急。记住，备份策略不是越全越好，而是恢复越快越好。
说到恢复，很多人以为就是把备份文件导回去，，完事。但这里有个大坑，你备份的时候得考虑数据一致性。如果备份过程中有人正在写数据，导出来的文件可能前后矛盾，恢复回去数据就乱了。解决办法是在mysqldump命令里加参数，对InnoDB表来说，它能在备份时开启一个事务，保证你看到的是某个时间点的快照，而不是东拼西凑的碎片。这个参数不加，早晚出事。
还有个细节，我每次备份都会加。为啥？因为如果你用的是主从架构，备份文件里带着GTID信息，恢复的时候容易和主库的GTID冲突，导致从库同步中断。这个坑我踩过一次，当时大半夜被叫起来，从库同步断了三个小时，查了半天才发现是备份文件里多了一行SET语句。从那以后，我所有备份脚本里都强制加上这个参数，再也没出过类似问题。
备份文件存哪儿？放本机硬盘上等于没备份。机器挂了，硬盘跟着一起走，你哭都来不及。我的做法是，备份完自动用rsync同步到另一台服务器，同时再打包压缩传到对象存储上。你千万别嫌麻烦，多存一份，就是多一条命。我有个客户，数据库被误删了，结果发现备份文件就在同一台机器上，而机器已经起不来了，只能找数据恢复公司，花了几万块，还不一定能全找回来。这教训够深刻吧。
恢复的时候也别大意，先别急着导生产库。我的习惯是，先恢复到一台临时实例上，验证一下数据的完整性和一致性，比如查一下关键表的行数，跑几个常用查询，确认没问题了，再正式切换。你想想，如果恢复完发现某个表少了一部分数据，那还不如不恢复。验证这一步，花不了十分钟，但能帮你避免二次事故。
说个容易被忽略的点，备份脚本要定期演练。别笑，真有人备份了半年，结果恢复的时候发现备份文件是坏的，或者格式不对。我建议每季度找一台测试机，把最新的备份文件恢复一遍，确认能跑起来。这跟消防演习一个道理，平时不练，真着火的时候手忙脚乱。mysqldump这东西，说到底是给有准备的人用的，你准备得越充分，数据库就越安全。
说到底，mysqldump备份恢复数据库，技术门槛真不高，难的是你愿不愿意花心思把细节做好。加个参数、换个存储位置、多验证一次，这些小事积累起来，就是你和事故之间的距离。下次有人问你数据库安全怎么搞，你可以淡定地告诉他：备份先做好，恢复要练熟，其他的，都是后话。
