做运维和开发的朋友，十有八九都碰过这种糟心事：手一抖，DROP TABLE敲下去，或者UPDATE忘了加WHERE，整张表的数据说没就没。数据库备份是全量的，好几G甚至几十G的文件，为了恢复一张只有几百MB的表，得把整个实例停掉，把全量备份导进去，再追binlog，搞不好还得让业务停个大半天。我见过太多人因为这种“为了救一条鱼，把整个池塘抽干”的操作，被领导骂得狗血淋头。其实MySQL完全支持只恢复单个表，前提是你得用对工具，用对姿势。
最直接的办法，是用mysqldump单独导出那张表。很多人平时备份习惯性地用，恢复的时候也想当然地全量导入。但mysqldump本身就支持指定库表，比如你只需要恢复表，直接，就能只导出这一张表的结构和数据。如果你已经有全量备份文件，但只想从里面抠出某张表，那就得配合或者来定位。不过说实话，用文本处理工具去切一个几G的SQL文件，效率低不说，还容易出错，我后面会讲更靠谱的办法。
如果你用的是Percona XtraBackup这种物理备份工具，恢复单表就更有讲究了。物理备份是整个数据目录的拷贝，里面是文件，不能直接拷回去用。但XtraBackup提供了参数，可以在备份时只备份指定表。如果你已经做了全量物理备份，想恢复单表，标准做法是先用XtraBackup把备份恢复到临时实例，然后把目标表的文件和文件单独导出，再导入到生产实例。这个过程涉及和，稍微有点繁琐，但胜在不用全量恢复。
说起和，这是MySQL 5.6以后提供的一个非常实用的功能，专门用来做单表恢复。流程是这样的：先在目标库上建一张同名的空表，结构和原表完全一致，然后，这时候MySQL会删掉该表的文件。接着把备份里对应表的文件复制到该库的数据目录下，，MySQL就会去读取这个文件并挂载上。这个方法的好处是速度快，不用经过SQL解析，适合大表。但有个坑必须提醒你，原表和备份表的版本必须一致，也得对得上，不然导入会报错。
再讲一个日常操作里很多人忽略的场景。有时候表没删，但数据被误操作清空了，比如。这时候如果开启了binlog，并且binlog格式是ROW，那就还有救。你可以用工具，把binlog解析出来，找到误操作的那条语句之前的日志，反向执行。具体来说，先用把binlog转成可读文本，然后找到之前的一个事务，把那个事务里的INSERT语句提取出来，重新执行一遍。这个方法能精准恢复被清空的数据，但前提是你得知道大概的误操作时间点，而且binlog要完整。
对于云数据库，比如阿里云RDS、腾讯云CDB，它们自带的控制台通常都有“库表恢复”功能。这个功能本质上是后台帮你做了单表恢复，但使用体验比命令行友好太多。你可以选择某个时间点，然后勾选要恢复的库或表，系统会自动创建一个临时实例，把数据恢复出来，再让你选择是覆盖原表还是生成新表。这里有个小技巧，如果你不确定表结构有没有被改过，可以选择恢复到新表，对比一下数据量和业务逻辑，确认没问题后再切换。用云数据库的人，千万别去下载整个物理备份自己折腾，效率低还容易出问题。
说到对比，我强烈建议你在恢复前先做一件事：检查表结构是否一致。特别是用的时候，如果原表的索引、字段顺序、字符集跟备份表有差异，导入过程会直接报错。你可以用先看下当前表结构，再跟备份文件里的建表语句比对。不一致的话，先调整当前表结构，比如加索引、改字符集，然后再执行DISCARD和IMPORT。别嫌麻烦，这一步能省掉后面很多莫名其妙的报错。
给你一个压箱底的建议：对于核心业务表，别只依赖全量备份，可以单独为它做定期导出。比如每天凌晨用mysqldump把最重要的几张表单独备份一份，压缩后放到别的存储上。这样万一出事，你连全量备份都不用翻，直接拿最近的一次单表备份恢复，数据丢失量最多就是一天的量。如果业务允许，还可以考虑用pt-table-checksum和pt-table-sync这类工具做定期校验，防患于未然。记住，恢复单表的核心思路就是把影响范围控制到最小，别动不动就全库恢复，那是最后的手段。掌握了上面这些方法，再遇到表被误删，你就能从容应对，而不是手忙脚乱地找运维同事擦屁股了。
