mysql-data 文件夹中的巨大 #sql-xxxx_xxxx.ibd 文件

Question

在我们的一个 mysql 数据库上，磁盘大小（28GB）比实际数据（~5GB）大得多，所以我仔细查看了 mysql-data 中包含的文件

我看到以下文件

12K     #sql-5254_eaa3.frm
8.9G    #sql-5254_eaa3.ibd
12K     #sql-537f_8d5b.frm
11G     #sql-537f_8d5b.ibd

即使在 mysql 重启、服务器重启等之后，上述内容仍然存在

知道这些是在崩溃中幸存下来的临时表吗？在生产系统上删除它们是否安全，还是需要以不同的方式处理它们？

顺便说一下，我们确实将 file_per_table 设置为 true。

提前感谢您的任何提示！

Answer 1

您看到的表文件很可能是由无法完成的 ALTER TABLE 操作产生的。MySQL 文档的相关部分说：

如果 MySQL 在 ALTER TABLE 操作过程中崩溃，您可能会在 InnoDB 表空间内得到一个孤立的临时表。使用表监视器，您可以看到列出的名称以#sql- 开头的表。如果将名称括在反引号中，则可以对名称包含字符“#”的表执行 SQL 语句。因此，您可以像使用前面描述的任何其他孤立表一样删除这样的孤立表。在 Unix shell 中复制或重命名文件，如果文件名包含“#”，则需要将文件名放在双引号中。

所以我会简单地DROP TABLE对它们发出一个。注意：不要简单地删除文件- 否则你会得到所谓的孤立表，产生这样的数据库引擎警告：

InnoDB: in InnoDB data dictionary has tablespace id N,
InnoDB: but tablespace with that id or name does not exist. Have
InnoDB: you deleted or moved .ibd files?
InnoDB: This may also be a table created with CREATE TEMPORARY TABLE
InnoDB: whose .ibd and .frm files MySQL automatically removed, but the
InnoDB: table still exists in the InnoDB internal data dictionary.

Answer 2

我意识到这可能是临时文件..最好的是如果你可以：

• 转储整个数据库

mysqldump -uuser -ppass 数据库 > 文件

• 删除数据库并从转储中重新创建它

猫文件| mysql -uuser -ppass 数据库

来自底部的警告仍然适用。

我最初的回答：

这些名称与您的表的名称相对应吗？很可能是的，如果是的话 - 这些只是数据文件。innodb 存储引擎 [ibd 扩展建议您使用它] 永远不会收缩数据文件。使它们变小的唯一方法是：

• 转储每个表并重新创建它：

mysqldump -uuser -ppass 数据库表名 > 文件 ; 猫文件| mysql -uuser -ppass 数据库

• 运行“优化表表名；” 在 mysql 中每个“大”表

警告 - 这两个操作都会花费大量时间[很大程度上取决于表中的索引数量、您的 io 子系统；我们很可能谈论的是几个小时（如果不是更多的话）；会阻塞读取。不要在生产时间内运行它。