MySQL 数据库损坏症状与恢复流程
MySQL 的损坏有个特点——"散"：一个实例几十上百张表，坏点分散、排查面广。先把症状认全，再按引擎和场景定方案。
症状清单
服务层：mysqld 启动失败或卡在 InnoDB 恢复阶段反复崩溃；报 ibdata1、ib_logfile、表空间文件错误；ERROR 2002 服务没起来。错误日志信号："Database page corruption on disk"——InnoDB 页损坏的头号报错；"Table is marked as crashed and should be repaired"——MyISAM 招牌报错；"Table doesn't exist in engine"——frm 表结构文件和 ibd 数据文件失联。查询层：查特定表报错其他表正常；ERROR 2013 Lost connection 查询触发崩溃。数据异常：乱码、行数对不上、自增主键冲突。特色坑：误删 .ibd 文件后 show tables 里表还在、一查就报错；断电后表锁不释放；ibdata1 膨胀损坏拖垮整个实例。
恢复流程
第〇步保现场：立即停写，整个 data 目录冷拷贝（ibdata1、所有 .ibd/.frm、redo/undo、binlog）——必须停服务后拷，热拷的文件内部不一致等于没拷。有备份走正道：mysqldump/xtrabackup 还原 + binlog 前滚，误删表能恢复到出事那一秒；有主从的从节点直接顶上来。无备份分引擎：MyISAM 相对简单，停服务后 myisamchk -r 修（在线修等于雪上加霜）；InnoDB 三板斧逐级升级——第一斧 innodb_force_recovery 从 1 级试到 6，能启动就立刻 mysqldump 导出灌新库；第二斧单表手术，frm 还在 ibd 坏了的，DISCARD TABLESPACE→拷入 ibd→IMPORT TABLESPACE 单独捞回；第三斧页级抽取，用 undrop-for-innodb 类工具直接扫数据页硬抽行记录。
特殊场景
误删 ibd/误删库：立即停止一切写入，从文件系统层面恢复；表在老架构 ibdata1 共享表空间里的，按表空间 ID 捞。误操作（drop/update 搞错）：binlog 还在就是宝——用 flashback 类工具逆向生成回滚 SQL，秒级回滚。frm 丢失：从备份翻建表语句，或用工具从 ibd 数据页反推表结构。
警示
别先急着设 innodb_force_recovery 强拉——1 到 6 级级别越高丢弃越多，6 级连 undo 都不要了；每试一级都先备份一份，拉起来的库只用于导出，绝不当生产库用。记住顺序：停写 → 备份 → 再修，一个都不能少。
常见问题
MySQL 数据库表损坏怎么修复？
先分引擎：MyISAM 用 myisamchk 或 REPAIR TABLE（必须停服务）；InnoDB 用 force_recovery 逐级试启动后导出重建，单表坏的做 DISCARD/IMPORT TABLESPACE 手术，彻底打不开的上页级抽取工具。
误删了 MySQL 的 ibd 文件能恢复吗？
可以。误删后立即停写，从文件系统层面恢复文件；文件被覆盖的，按表空间 ID 从 ibdata1 或底层扇区残留里捞数据。动作越快，覆盖越少。
innodb_force_recovery 设置几级？
从 1 级开始逐级试，能低不高：1-2 级基本无损，3 级跳过回滚，6 级连 undo 都跳过数据可能脏。每一级都先备份，启动成功的唯一目的是导出数据重建新库。
MySQL 有 binlog 能恢复到任意时间点吗？
可以。完整 binlog 加全量备份，能按时间点前滚恢复——误删表、误 UPDATE 都能回到出事前。前提是 binlog 开着且没被清理，这也是防复发的第一建议。
MySQL 主从复制等于备份吗？
不等于。主从是同步复制：误删操作秒级同步到从库，主从一起中招。真正的备份是 mysqldump/xtrabackup 定期逻辑备份，加 binlog 归档。