去年对数据库一个大表做了 optimize 操作,由于不了解具体操作就草草执行了。此操作会拷贝原表数据到临时表,如果此时硬盘空间不够,就会报错,或者表太大,执行时间将及其漫长,反正哪种都是不可接受的。

这是当时的日志
image

当时就把进程 kill 掉了,但是留下了一个 75G 没有用的临时表,后来因为服务器加了硬盘空间,就没有去管它。最近硬盘又快占满,这个 75G 废弃文件实在碍眼,就着手看看怎么安全删除。

首先暴力 rm 必定不可取,参考互联网资料,这个应该是官方的一个解决方案
https://mariadb.com/resources/blog/get-rid-of-orphaned-innodb-temporary-tables-the-right-way/

image

试着按参考链接执行建同名表,正常建表命令肯定不会影响数据库,找到原来的表结构建表
CREATE TABLE #sql-5df6_36c (
id bigint(32) NOT NULL AUTO_INCREMENT,
card varchar(50) DEFAULT NULL COMMENT ‘卡券号’,
createTime datetime DEFAULT NULL COMMENT ‘创建时间’,
status varchar(1) DEFAULT NULL COMMENT ‘状态’,
posData text COMMENT ‘POS请求的数据’,
ffData text COMMENT ‘飞凡返回的data’,
reason varchar(500) DEFAULT NULL,
PRIMARY KEY (id),
KEY card_index (card)
) ENGINE=InnoDB AUTO_INCREMENT=152943355 DEFAULT CHARSET=utf8;

image

结果残缺的 #sql-5df6_36c.frm 被自动删掉
image

接下来剩下缺失表结构的大文件
cp cc_card_log.frm /app/mysql/data/watsons_coupon/#sql-ib2460-3936078760.frm
复制表结构命名与临时表相同

image

再 drop 表,提示表不存在
image

先再建表
image

可以看到与临时表同名多会生成这两个文件,原来的两个文件也还在的
image

再试试 drop 表
image

发现不行,四个文件都还在
再尝试
image

@[email protected]@002d3936078760 两个文件倒是删掉了

#sql-ib2460-3936078760 两个还好好的
仔细一看

#sql-ib2460-3936078760.frm 用户组用户都是 root ,cp 的时候用了 sudo 执行,需要授权用户

chown mysql:mysql #sql-ib2460-3936078760.frm
image

再 drop 表
image

75G文件5s多drop掉,总算删掉了