在我们的一个 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。
提前感谢任何提示!
答案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.
答案2
我实现这可能是临时文件..最好的是如果你可以:
- 转储整个数据库
mysqldump -uuser -ppass 数据库 > 文件
- 删除数据库并从转储中重新创建它
cat 文件 | mysql -uuser -ppass 数据库
来自底部的警告仍然适用。
我最初的答案:
这些名称是否与您的表的名称相对应?很有可能是的,如果是这样 - 这些只是数据文件。innodb 存储引擎 [ibd 扩展建议您使用它] 永远不会缩小数据文件。使它们变小的唯一方法是:
- 转储每个表并重新创建:
mysqldump -uuser -ppass 数据库表名 > 文件 ; cat 文件 | mysql -uuser -ppass 数据库
- 在 mysql 中对每个“大”表运行“optimize table tableName;”
警告- 这两个操作都将花费大量时间[很大程度上取决于表中的索引数量、你的 io 子系统;很可能我们谈论的是数小时甚至更多的时间];将阻止读取。请勿在生产时间运行此操作。
答案3
这可以是临时文件,例如在长时间执行的 ALTER 命令期间。
通过检查其随时间推移的大小,确保它目前没有被长期命令使用。
如果它没有增长,您可以使用 MySql
DROP
- 命令安全地删除该表(不要只删除控制台上的文件,这可能会导致出现孤立表)