问题
我写错了脚本，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 的技术内容，你们还有什么想知道的吗？赶紧留言告诉小编吧！
