背景：公司生产环境服务器空间报警，超过80%，紧急检查发现是mysql备份服务器，有一个记录明细的大表，占用空间150G左右。找到了问题，就要解决他。计划将此表移走，重新建一个空新表，继续记录。在操作过程中因为失误，导致多饶了好多流程，现在记录下来。
原计划：
1、备份这个表，使用xtrabackup
2、对表空间进行硬链接（ln命令），目的是不删除文件本身，而只删除其指针，从而达到快速删除，不影响使用，不占用资源的目的。（依赖原理：OS HARD LINK 当多个文件名同时指向同一个INODE时,这个INODE的引用数N>1, 删除其中任何一个文件名只是删除了一个指针而已，不会删除数据文件。当INODE的引用数N=1时, 删除文件需要去把这个文件相关的所有数据块清除,所以会比较耗时）。
3、使用drop删除表，最后删除表文件。
问题：然而理想很丰满现实很骨干，打我登陆服务器之后，发现服务器剩余的空间不足以让我进行硬链接。这就尴尬了，没办法，只能另找其他方法。
实际操作：
1、备份完数据
2、思索怎么把大表删除或者移走。最后决定将表空间重命名（mv），然后再操作，但是在mv重命名过程中，因为失误将ibd文件覆盖了，导致的问题是此大文件瞬间消失了，但是查看服务器空间发现其所占空间大小依然存在。按照道理来说，如果mv导致文件覆盖，文件相当于是被删除了，空间也应该释放了，然而没有。考虑到文件为mysql表空间文件，可能存在链接问题，重启mysql后，发现硬盘空间释放。
3、解决了硬盘空间问题，迎来了新的问题。在原数据库中建立同名表的时候，数据库一直提示表已存在，这就是直接删除表空间遗留下的问题。因为要新建一个空表，继续使用，所以也要解决这个问题。当然如果条件允许的话，可以另见一个结构一样表名称不一样的新表使用。我认为既然遇到了，就解决这个问题。
4、登陆数据库进行drop表测试，发现提示找不到这张表t1。考虑到表空间不存在，手动建一个空的表空间。首先是建了一张结构一样但是表名称不一样的表t2，复制t2的表空间并重命名为t1的表空间。重启数据库，然后再进入数据库，先分离表空间，再drop表，发现可以成功。然后新建t1表，也可以成功。最后将t2表删除。
5、此操作虽然没有问题，但是t1表中原始数据会丢失，所以在操作数据库之前一定要备份数据。
总结：虽然这是一个不大不小的问题，特别记录下来，有需要的朋友可以看一下。当然也有一个意外收获，那就是这样删除比drop速度要快得多，而且还不占用资源。