干这行十几年，最怕听到的就是那句“卧槽，数据没了”。尤其是MySQL，平时老老实实跑着没事，一旦误删、断电、磁盘故障，瞬间就能让人从工位上弹起来。我见过太多人第一反应是去百度“怎么恢复”，结果越折腾越糟。今天这篇不整虚的，全是实操里砸出来的经验，从最基础的备份回滚到冷门但救命的各种奇招，你按顺序看下去，至少能保住九成以上的数据。
先说最笨但最管用的办法：物理备份文件。很多人不知道，MySQL的数据其实就躺在磁盘上那几坨文件里，特别是用MyISAM引擎时，每个表对应独立的.frm、.MYD、.MYI文件。如果你之前做过冷备份（停库拷贝整个data目录），恭喜你，恢复就是解压覆盖的事。但注意，覆盖前一定把原目录改名留底，别直接删，万一新文件不全你还能退回去。InnoDB引擎稍微麻烦点，它把数据存在ibdata1和一堆.ibd文件里，但只要你备份了完整的data目录，照样能整个拷回去，前提是MySQL版本要一致，跨版本容易报错。
再说热备份的恢复。现在正经生产环境都用mysqldump或者Percona XtraBackup做定期备份。mysqldump出来的.sql文件恢复最简单，mysql -u用户名 -p密码 库名 < 备份.sql，一行命令搞定。但有个坑——如果你备份时没加--single-transaction，那备份过程中写入的新数据会混进去，恢复出来的数据可能前后不一致。所以恢复前最好先看下备份文件头部的注释，确认用的什么参数。XtraBackup恢复稍微讲究点，它产生的是物理备份，需要先执行xtrabackup --prepare把日志回放一遍，让数据文件处于一致性状态，然后再复制回data目录，启动服务前记得检查下权限，别让MySQL跑起来后没权限读文件。
误删数据是最高频事故，这里必须说binlog。只要你的MySQL开了binlog（默认是开的，但很多人没注意），那就有后悔药。具体操作分两步：先找到误删的时间点，用mysqlbinlog工具把那个时间段的日志解析出来，比如mysqlbinlog --start-datetime="2023-06-01 10:00:00" --stop-datetime="2023-06-01 10:30:00" binlog.0012 > 恢复.sql，然后直接导入。但有个细节，如果误删的是整张表，你得先重建表结构，再导入binlog里的INSERT语句。更麻烦的是，binlog里可能混着DROP、DELETE，你得手动把那些语句删掉，只保留你想要的数据变更。我建议用mysqlbinlog加--base64-output=DECODE-ROWS配合--verbose，把binlog转成可读的SQL，再编辑过滤。
万一连binlog都没开，或者日志被覆盖了，那就得靠工具硬抠。这里推荐一个神器叫mysqlfrm，它能从.frm文件里反推建表语句。表结构还在，数据在.ibd文件里，但InnoDB的表空间文件如果没损坏，你可以用ibd2sdi工具（MySQL 8.0自带）把里面的表结构定义导出来，然后用ALTER TABLE IMPORT TABLESPACE的方式把数据导回新表。这招我试过多次，成功率挺高，但前提是你之前启用了innodbfilepertable（每表独立表空间），否则所有数据混在ibdata1里，那就得用更底层的工具了，比如Undrop for InnoDB，这玩意儿能直接扫磁盘上的数据页，但操作复杂，还得编译，建议非资深DBA别轻易尝试，容易把磁盘搞得更乱。
还有个常被忽略的场景：MySQL主从复制出问题导致数据不一致。这种情况不要慌，先看从库的relay log，里面存着主库发过来的所有变更。如果你从库只是延迟，那等它追上就行；如果已经报错停住了，可以用mysqlbinlog解析relay log，找到出错的那条SQL，手动跳过或者补执行。更高级的做法是，如果你有全部binlog，可以临时把从库改成指向一个假的binlog位置，强制它继续跑，但这样会丢失部分数据，所以慎用。我一般先检查从库的SecondsBehind_Master，如果数值一直不变反而说明卡死了，这时候看error log定位具体问题，比盲目重搭从库靠谱得多。
说个很多人不知道的土办法：用快照或文件系统级恢复。如果你用的是云数据库RDS，一般都有自动备份和日志备份，开通PITR（时间点恢复）功能后，能恢复到任意秒级。但自建机房的话，Linux上可以用LVM快照，或者干脆用ZFS/Btrfs这类带快照的文件系统。原理很简单，你定期对数据目录所在的卷打快照，恢复时直接回滚到误删前那个快照点。这招特别适合那种“昨天还好好的，今天一早发现数据被清了”的场景，只要快照周期覆盖到了，恢复就是几分钟的事。不过提醒一句，快照不是备份，它依赖同一份物理存储，磁盘整个坏了，快照也一起没了，所以该做的异地备份还得做。
写了这么多，其实最核心的就一句话：数据恢复拼的不是技术，是习惯。你平时有没有开binlog、有没有定期备份、备份完有没有验证过能不能恢复，这些决定了出事时你是喝杯咖啡慢慢搞，还是连夜打飞机去机房。我见过太多公司，备份脚本跑了两年，结果恢复时发现备份文件是坏的，那种绝望比数据丢了还难受。所以别嫌麻烦，每个月至少做一次恢复演练，把备份文件拷到一台测试机上真刀真枪地恢复一遍。真到了用的时候，你会发现，所有技巧都建立在“手上有货”的基础上。
