更新到 MySQL 5.7 和高磁盘空间消耗

Question

使用：Debian 9 上的 MySQL 5.6，总 DB 大小约为 450Gb

更新到 5.7，运行 mysql_upgrade，注意到大约 150 GB 已被占用。 2 个表真的很大，他们在“复制到 tmp 表”中停留了几个小时

注意到innodb_file_per_table 已打开并创建了以前不存在的大型 ibd 文件。

从快照恢复，禁用 file_per_table，再次运行 mysql_upgrade。 100GB 消失了，几乎是我总 DB 的 1/4。

在第一种情况下，它从 ibdata 中提取数据并将其放入单独的文件中，但 ibdata 从未缩小，因此占用的空间几乎翻了一番。

第二种情况会发生什么？临时表是否在永远不会缩小的 ibdata 文件中创建，因此即使不再使用表 - 空间仍然没有？

我注意到的另一件事是，直到查询复制到 tmp 表状态大约一个小时后才会开始占用空间。

1) 有什么方法可以避免/最小化空间增加？

是否会在打开 file_per_table 的情况下运行更新，然后禁用它并运行 alter table engine innodb 释放空间？

2) 有什么方法可以预测会占用多少空间？至少每张桌子

3) max_tmp_table_size 如何参与其中？

Answer 1

在没有磁盘膨胀的情况下切换到file_per_table的唯一（？）方法是

1. 转储数据。
2. 重新安装（或以其他方式删除 ibdata1）。
3. 重新加载（打开 file_per_table）。

Answer 2

听起来你从一开始就没有运行 innodb_file_per_table 把自己画到了一个角落，所以现在你有一个巨大的、不可收缩的 ibdata1 文件。

1) 没有。

1.1) 它可能会通过在 ibdata1 文件外部重建表，然后再次将它们重建到 ibdata1 内部来减少总体空间使用量，重用 ibdata1 内部的一些未使用空间

2) 是的：

SELECT TABLE_SCHEMA, TABLE_NAME, DATA_LENGTH, INDEX_LENGTH FROM information_schema.TABLES;

3) 它没有。您看到的表可能是由于某种原因正在重建的表（不知道为什么，我不得不承认我之前没有看到 mysql_upgrade 发生这种情况）。 max_tmp_table_size 仅用于隐式（当查询计划显示using temporary）和显式（CREATE TEMPORARY TABLE ...）临时表，不适用于表重建。