1

使用：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 如何发挥作用？

4

2 回答 2

1

听起来你从一开始就没有运行 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 ...）临时表，不适用于表重建。

于 2020-05-12T18:54:03.717 回答
0

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

  1. 转储数据。
  2. 获得全新安装（或以其他方式摆脱 ibdata1）。
  3. 重新加载（打开 file_per_table）。
于 2020-06-01T20:30:21.273 回答