myisam表可直接拷贝.myd/.myi文件恢复，因数据与索引物理分离且无事务依赖；innodb表不可直接拷.ibd文件，因其依赖ibdata1元数据、事务日志等完整上下文，强行拷贝将导致表空间缺失或校验失败。
MyISAM 表能直接拷文件恢复，InnoDB 表不能——除非你只想要“看起来像恢复了”，实际数据可能已损坏或丢失。
MyISAM 直接拷 .MYD/.MYI 文件为什么有时能用
MyISAM 是堆表结构，数据（.MYD）和索引（.MYI）是独立的物理文件，不依赖事务日志。只要 MySQL 服务已停止、文件没被覆盖、且表没在写入中被截断，拷贝原文件到新实例的 datadir/<db_name>/</db_name> 下，重启后 SHOW TABLES 就能看到表，SELECT 也可能查出数据。
但要注意这些坑：
- 如果原表正在被写入，而你没停服务就 cp，
.MYD可能处于中间状态（比如 INSERT 半截），导致SELECT报错Incorrect key file for table 'xxx'; try to repair it - 拷完不执行
REPAIR TABLE xxx，后续查询可能跳过损坏行，或突然崩溃 - 如果原库开启了
delay_key_write，索引可能还在内存没刷盘，.MYI文件本身就不完整 - 跨版本拷贝（如从 5.7 拷到 8.0）大概率失败，
.frm格式或字符集定义不兼容
InnoDB 拷 ibd 文件几乎必然失败
InnoDB 的 .ibd 文件不是孤立存在的。它依赖 ibdata1 中的元数据、事务系统信息、undo log、buffer pool 状态等。直接把一个 t1.ibd 拷到另一个实例，即使表结构一致，MySQL 启动时也会报 Tablespace is missing for table 'db.t1' 或更隐蔽的 innodb_checksum_algorithm mismatch。
真正可行的路径只有两条：
- 用
ALTER TABLE t1 DISCARD TABLESPACE+IMPORT TABLESPACE流程，但前提是：你有匹配的.cfg元数据文件（mysqldump 出的--tab或xtrabackup备份里才有），且innodb_force_recovery=0，且表没被修改过 - 用
xtrabackup --copy-back完整还原整个实例，这是唯一被 MySQL 官方认可的物理文件级恢复方式
别信“删库后立刻 cp /var/lib/mysql/db/t1.ibd 到新机器就能用”这种说法——那只是把损坏状态复制过去了。
binlog 日志恢复只对 InnoDB 有效，且必须满足三个硬条件
所谓“用 binlog 恢复误删数据”，本质是重放日志中的 DML/DDL 语句。但这对 MyISAM 和 InnoDB 完全不同：
- MyISAM 不支持事务，
binlog_format=ROW下它也能记录变更，但一旦发生DROP TABLE或TRUNCATE，就彻底没得闪回——binlog 里只有“删了”，没有“删之前长啥样” - InnoDB 要做精准恢复，必须同时满足：
binlog_format=ROW、binlog_row_image=FULL、且误操作前没执行过OPTIMIZE TABLE（会清空旧版本 row image） - 用
mysqlbinlog --base64-output=DECODE-ROWS -v解析出来的UPDATE@1记录，才是能反向生成 DELETE 语句的基础；否则你看到的只是### UPDATE `db`.`t1` SET @1=2 WHERE @1=1这种模糊映射
最常被忽略的一点：恢复前先确认 MySQL 进程是否还在打开被删文件
Linux 下，即使你执行了 rm -f /var/lib/mysql/db/t1.ibd，只要 mysqld 进程仍在运行且该文件句柄未关闭，/proc/<pid>/fd/</pid> 里还能看到它。这时用 cp /proc/<pid>/fd/<fd_num> ./t1.ibd.recovered</fd_num></pid> 可抢回一份完整副本——这是唯一不需要备份、不依赖 binlog 的“后悔药”。但窗口期极短：一旦 mysqld 重启或主动 FLUSH TABLES，句柄立即释放，磁盘空间被标记为可覆盖。
