1. 现象
巡检时发现服务器磁盘空间不足,通过查看大文件进行筛选是发现有几个#sql开头的文件,且存在超过100G及10G以上的文件。
![991db7f640ed201364637168b6481221.png](https://i-blog.csdnimg.cn/blog_migrate/1f4ac01bf71ff6b6ccce15a73d708204.jpeg)
2. 原因
如果MySQL在一个 ALTER TABLE操作(ALGORITHM=INPLACE)的中间退出,那么可能会留下一个占用系统空间的临时表。例如,在对一张表(大表)添加索引时中途中断、磁盘不足导致异常或正在添加索引时实例被kill等等情况所致。注意: 此类表空间文件不能直接rm -f的方式物理删除,因为该信息记录在ibdata的共享表空间里,直接删除后,后续实例重启时会出现错误。3. 处理方法3.1 同时存在.frm 和.ibd名称相同的文件
如果 #sql-*.ibd 和 #sql-*.frm两个文件都存在数据目录里的话,可以直接drop table。但注意删除时候表名的变化。
/* 直接删除,表名前加#mysql50 */
root@testdb 01:42:57> DROP TABLE `#mysql50##sql-ib87-856498050`;
注:#mysql50#前缀是MySQL 5.1中引入的文件名安全编码。另外,表名因不符合命名规范,想要执行该脚本需要将表名用反引号括起来。3.2 创建新表方式删除
因为本例中没有存在.frm 和.ibd名称相同的文件的情况,因此采用创建一张与ibd表空间对应的结构(字段名及索引)一致的表,然后将frm文件拷贝为和ibd一致的文件,再进行删除。
下面处理截图中#sql-ib1516-2335726735.ibd文件,步骤如下:a) 创建一张与#sql-ib1516-2335726735相同的表
root@testdb 08:47:35>create table company20191216 like company;
Query OK, 0 rows affected (0.05 sec)
root@testdb 08:48:59>exit Bye
b) 拷贝为#sql-ib1516-2335726735.frm的定义文件
[root@db4 testdb]# cp -p company20191216.frm #sql-ib1516-2335726735.frm
c) 删除表
因为上一步拷贝时使用-p的方式,即权限和原文件权限一致,属主及group均为mysql,因此可以直接在数据库里读取删除,如果权限不对,必须先修改文件权限。
root@testdb 08:49:54>drop table `#mysql50##sql-ib1516-2335726735`; Query OK, 0 rows affected (6.65 sec)
此时,135G的文件就已经删掉了(其实另一个文件#sql-821_2.frm文件也一并删了)
![b50d4552433adace1c8749ed1e57a753.png](https://i-blog.csdnimg.cn/blog_migrate/77658cd8aa2c47739340ca83f3ba061c.png)
注:删除这种100G的表不建议直接删除,而是通过创建硬链接的方式处理。3.3 修改frm文件名与ibd文件名一致
上一步中删除ibd文件时,其中一个frm也自动删除了。为此,尝试通过修改frm文件名和ibd文件名一致的方式处理。但要注意,由于不确定是否结构一致,修改后可能异常,但如果没有暴力处理,通常均可以成功。如下:a) 修改frm文件名与ibd文件名一致
[root@db4 testdb]# mv #sql-a846_2.frm #sql-ib1570-121877015.frm
b) 删除表
root@testdb 01:41:06>DROP TABLE `#mysql50##sql-ib1570-121877015`;
Query OK, 0 rows affected (1.70 sec)
![74dd555abcee9d6c498f092708b82645.png](https://i-blog.csdnimg.cn/blog_migrate/fb38ec063c05e3153ad5f862894b6a58.jpeg)
done!
其实还有其他的方式处理,大家可以自行测试。
参考资料:官方文档https://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html