我干数据库这行十多年，见过太多人栽在备份恢复上。平时不觉得，真到出事儿那天，手忙脚乱翻文档，才发现连最基本的mysqldump参数都记不全。今天不整那些虚的，直接把这几年用下来最实在的备份恢复命令捋一遍，你照着抄就行。
先说最常用的逻辑备份工具mysqldump。这玩意儿简单粗暴，适合中小型库。单库备份就一条命令：mysqldump -u用户名 -p密码 数据库名 > 备份文件.sql。注意啊，密码别直接写在命令行里，用-p然后回车再输，否则history里全是你的密码，等于裸奔。要是库比较大，加上--single-transaction参数，InnoDB表能保证备份期间数据一致性，不用锁表。MyISAM表没这福利，只能锁表备份，所以线上生产环境我强烈建议全用InnoDB。
多库和全库备份也不难。多库用--databases参数，后面跟库名，比如mysqldump -uroot -p --databases db1 db2 > 多库备份.sql。全库就加个--all-databases，连系统库一起备。这里有个坑，很多人备份时把mysql库也备了，恢复的时候容易出权限问题。我一般只备业务库，系统库单独处理。
光有备份不行，还得会恢复。逻辑备份恢复就一条命令：mysql -u用户名 -p 目标库名 < 备份文件.sql。但这里有个前提，目标库得先建好，不然会报错。所以恢复前先CREATE DATABASE，再执行导入。要是备份文件里有建库语句，那就不用管，直接mysql -uroot -p < 备份.sql就行。
还有个更快的恢复方式，用source命令。进到mysql命令行里，use 库名，然后source /路径/备份文件.sql。这比外部管道导入快不少，尤其文件大的时候差距明显。我习惯用这个，因为能看到进度，心理踏实。
说完逻辑备份，再聊聊物理备份。数据量上了几十G，mysqldump就有点吃力了，备份和恢复都慢。这时候用物理备份，直接拷贝数据文件。最简单粗暴的方式：停库，把datadir整个目录打包，恢复的时候解压回去，改一下权限就行。但生产环境不能老停库啊，所以有了Percona XtraBackup这个神器。它能在线热备InnoDB表，备份时不阻塞读写。
XtraBackup备份命令：xtrabackup --target-dir=/备份路径 --user=root --password=密码。恢复分两步：先prepare，把备份文件里的redo log应用进去，让数据文件保持一致；再copy-back，把文件拷回datadir。注意，恢复前datadir得清空，否则报错。这套流程我走了无数遍，稳定可靠，就是命令参数多，容易忘。
还有种场景，只误删了几行数据，全量恢复太亏。这时候用binlog做时间点恢复。前提是开启了binlog，且备份文件之后的所有binlog都还在。恢复步骤：先恢复最近一次全量备份，然后从备份时刻起，把binlog重放到误操作之前的时间点。命令是mysqlbinlog --stop-datetime="2024-01-01 00:00:00" binlog.001 | mysql -uroot -p。这操作能救命，但前提是你平时就得开启binlog，别等到出事了才后悔。
提醒一句，备份脚本别只写在服务器上，定期下载到本地或者其他机器。服务器磁盘坏了，备份文件也跟着没了，那才叫欲哭无泪。我见过一个客户，定时任务跑得好好的，结果磁盘满了，备份文件全损坏，数据库崩了恢复不了，整个公司停摆两天。所以，异地备份、定期恢复演练，这俩事儿比研究命令本身重要得多。命令就这些，关键是养成好习惯。下次再遇到数据库出问题，你至少知道该往哪个方向跑。
