干这行久了，你就会发现，数据库这东西，平时安安静静躺在服务器里，像个老实人。可一旦它出了岔子——误删、宕机、被黑——你才想起来备份，那就已经晚了。我见过太多人，平时不烧香，临时抱佛脚，对着一个空空的data目录欲哭无泪。MySQL备份和还原，真不是啥高深技术，但关键时刻能救命。今天不整那些虚头巴脑的，直接上干货，几种最实用的方法，你按需取用。
先说说最老牌、也最通用的逻辑备份工具——mysqldump。这玩意儿从MySQL 3.x时代就存在，活到今天依然坚挺，靠的就是简单、可靠、跨版本兼容性好。它的原理不复杂，就是把数据库里的表结构和数据，一条条生成SQL语句，存到一个文本文件里。等你需要还原的时候，再把这些SQL语句执行一遍，数据就回来了。用法也直白，一条命令搞定基础操作：。如果你想把整个实例所有库都备份，加个参数就行。这里提个醒，千万记得加参数，尤其对InnoDB引擎的表，不加这个参数，备份过程中如果有写入操作，备份出来的数据可能是不一致的，相当于备份了个残缺品。还有和，这俩参数默认是不导出的，如果你的库里有存储过程、函数、触发器，忘了加这两个参数，还原的时候就会报错，那场面，够你喝一壶的。
mysqldump虽然好用，但有个硬伤——慢。当你库里的数据量到了几十GB甚至上百GB，mysqldump导出一个SQL文件可能要几个小时，而且导出的文件巨大，占用磁盘空间也吓人。这时候，就该物理备份登场了。物理备份的思路很简单粗暴，直接把MySQL的数据文件（也就是datadir目录下的那些ibd、frm、MYD、MYI文件）原封不动拷贝一份。备份的时候，你可以先停掉MySQL服务，然后直接tar打包整个数据目录，还原的时候把打包文件解压回去，重启服务就完事。这个方法速度快到飞起，因为就是文件拷贝，没有转换过程。但缺点也明显——必须是同一版本、同一平台，甚至小版本号不一致都可能出问题。你拿MySQL 8.0的备份文件去还原到5.7上，那基本就是痴人说梦。还有一种折中的物理备份方式，用或者它的继任者（Percona出品），这工具能在不停机的情况下做物理备份，还支持增量备份，对于生产环境的大库，这基本是标配方案。不过操作起来比mysqldump复杂不少，得先学一阵子才能上手。
说完了备份，重点聊聊还原。很多新手拿到一个备份文件，第一反应就是直接执行。这个没错，但要注意前提——你得先确保目标数据库存在。如果你备份的是单个库，还原前得先建好库，然后才能导入。如果是备份的，还原时直接导入就行，它会自动创建库。这里有个坑，还原过程中如果遇到外键约束、主键冲突，脚本可能会中途报错退出，所以建议导入时加上参数，让MySQL跳过错误继续执行。但加了这个参数也要谨慎，跳过的可能不是错误，而是数据完整性被破坏，所以最好还是先把备份文件检查一遍，确认没有明显问题再执行。
另外，热备份和冷备份的区别，你得心里有数。冷备份就是停掉服务再备份，简单安全但影响业务。热备份是服务运行中备份，mysqldump和xtrabackup都属于热备份工具。但热备份有个隐藏风险——如果备份过程中有DDL操作（比如ALTER TABLE改表结构），可能导致备份数据损坏。所以，建议备份尽量安排在业务低峰期，比如凌晨两三点，那时候写操作少，风险低。你要是图省事，白天高峰期直接备份，出了事别怪我没提醒你。
还有一个经常被忽略的点——备份文件的验证。很多人备份完，把文件往磁盘一存，就觉得自己高枕无忧了。但你有没有想过，那个备份文件可能是坏的？磁盘坏道、网络传输丢包、人为误删，都可能让你辛辛苦苦备份的东西变成一堆乱码。所以，定期做一次还原演练，找个临时环境，把备份导进去，看看数据能不能正常用。这就像买保险，平时感觉浪费钱，真出事才知道值不值。我建议，至少每个月做一次还原测试，尤其是生产环境的库，别等灾难降临了才追悔莫及。
说说自动化。手动备份容易忘，也容易出错，生产环境强烈建议用cron或者系统计划任务定期执行备份脚本。脚本里要包含几个要素：备份文件名带日期时间戳，这样方便追溯；备份完成后做压缩，节省空间；保留最近N天的备份，自动清理过期文件。比如你自己写个shell脚本，每天凌晨2点执行mysqldump，压缩后存到指定目录，删除7天前的旧备份。这样一套下来，你基本不用管它，数据安全有了保障，你也能睡个安稳觉。
回到标题说的那几种实用方法——mysqldump逻辑备份适合中小型库，灵活通用；xtrabackup物理备份适合大库，速度快增量给力；再加上定期还原演练和自动化脚本，这套组合拳打下来，你手里的MySQL基本上就是铜墙铁壁了。方法不在多，在于你真正用起来，并且能在关键时刻派上用场。别等到数据库崩了才想起这篇文章，那时候，你需要的可就不只是备份方法了。
