问题

我写错了脚本，ibd 文件被删除了，该往哪个方向逃跑？

实验

先来建一个测试库：

我们在这里开启了 innodb_file_per_table，但这个参数并非本实验所必须，只是为了演示方便。

然后模拟一个业务压力：

现在删掉相关的表文件：

可以打开地图 app，选择一个方向开始跑路了…

然而我们还可以挣扎一下，

查看一下 MySQL 占用的句柄：

找到被删除的表：

可以看到，除了临时表，被我们手工删除的表也在其中，对应文件句柄号 54。

现在我们把数据库的流量锁起来（如果使用了支持 offline_mode 的版本，可以设置 offline_mode）： 

现在记录一下表的记录数和校验值，以便跟恢复后的数据比较：

现在通过文件句柄找到消失的数据文件，并将其复制出来（此处注意磁盘空间）：

现在可以将数据库停下来，把恢复的数据复制到数据目录中，启动数据库：

看看数据是否正常：

看起来还不错。

实验原理

Linux 删除文件其实是减少了对文件的使用数，当使用数降为 0 时，才正式删除文件。

所以当我们执行 rm 时，由于 ibd 文件还在被 MySQL 使用，文件其实并没有被真实删除，只是没办法通过文件系统访问。

通过 procfs 查找文件句柄，可以让我们追踪到消失的文件。

思考题

即使我们停止了外部的数据压力，MySQL 也会自主做一些 buffer pool 的刷盘操作。

如果在我们复制数据文件的过程中，MySQL 触发了 buffer pool 的刷盘操作，那我们获得的数据文件不就不一致了么？是否会造成数据错误。

关于 MySQL 的技术内容，你们还有什么想知道的吗？赶紧留言告诉小编吧！