能抢救，前提是mysqld进程仍在运行且持有已unlink的句柄；需用ps aux | grep mysqld定位pid，再通过ls -l /proc/pid/fd/ | grep deleted确认存在“(deleted)”标记，随后cp /proc/pid/fd/x /var/lib/mysql/原路径恢复文件，并设置innodb_force_recovery后导出数据。
MySQL进程仍在运行但数据文件被误删怎么办
只要 mysqld 进程没退出，InnoDB 的 ibdata1、ib_logfile0 和表空间文件（如 test/user.ibd）即使被 rm 删除，仍可通过 /proc/<pid>/fd/</pid> 恢复——Linux 内核不会真正释放已打开文件的磁盘块，直到进程关闭或显式关闭句柄。
定位并复制被删但仍在使用的 InnoDB 文件
先确认 MySQL 进程 PID：
ps aux | grep mysqld
假设 PID 是 1234，进入其文件描述符目录：
ls -l /proc/1234/fd/ | grep deleted
常见输出类似：
lr-x------ 1 mysql mysql 64 Dec 5 10:22 12 -> /var/lib/mysql/ibdata1 (deleted) lrwx------ 1 mysql mysql 64 Dec 5 10:22 13 -> /var/lib/mysql/ib_logfile0 (deleted) lr-x------ 1 mysql mysql 64 Dec 5 10:22 25 -> /var/lib/mysql/test/user.ibd (deleted)
此时可直接用 cp 复制这些符号链接（内核会读取底层未释放的 inode）：
cp /proc/1234/fd/12 /backup/ibdata1.recoveredcp /proc/1234/fd/25 /backup/user.ibd.recovered- 务必加
.recovered后缀，避免覆盖原路径（原路径已不存在，但防止后续操作混淆） - 不要用
dd或cat——它们可能因缓冲或中断导致截断；cp在读取 deleted 句柄时行为最稳定 - 若表启用了
innodb_file_per_table=OFF，所有表数据都在ibdata1中，必须完整复制该文件，且不能跳过
恢复后能否直接替换启动？
不能。直接替换 ibdata1 或 .ibd 并重启 mysqld 极大概率触发崩溃或报错 Tablespace is missing for table 'test/user' 或 InnoDB: Database page corruption。
正确做法是：
- 停止 mysqld：
systemctl stop mysql（确保无新写入） - 将 recovered 文件放回原位置，例如
/var/lib/mysql/ibdata1 - 设置
innodb_force_recovery = 1（逐步尝试 1–6，从 1 开始）在my.cnf的[mysqld]段下 - 仅启动 mysqld 不加载引擎：
mysqld --skip-grant-tables --skip-networking（可选，用于紧急导出） - 优先用
mysqldump导出逻辑数据：mysqldump -u root --all-databases > full_backup.sql；若失败，再考虑innodb-tools或 Percona Recovery Toolkit 解析.ibd
哪些情况这条路走不通
如果出现以下任一情形，/proc/PID/fd/ 恢复法基本失效：
- mysqld 已异常终止（
kill -9或崩溃），句柄全部关闭 →/proc/PID/fd/目录消失 - 文件系统是 XFS 且启用了
allocsize=4k等激进分配策略，部分场景下 deleted 文件内容可能被后台回收线程覆盖（概率低但存在） - 使用了 MySQL 8.0+ 的数据字典表空间（
mysql.ibd）且该文件也被删 —— 它无法单独恢复，必须连同ibdata1一起复制，否则启动时报Failed to open the dictionary table mysql.innodb_index_stats - 误删的是 binlog 或 relay log：它们不被 InnoDB 引擎长期持有句柄，
/proc/PID/fd/中通常看不到
真正能靠句柄捞回来的，只有那些 mysqld 启动时就 open() 并一直 keep fd open 的核心数据与日志文件。其他路径，得靠 extundelete、photorec 或停机镜像 —— 但那就不是“未释放句柄”范畴了。
