更新到 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

聽起來你從一開始就沒有運行 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... ）臨時表，不適用於表重建。

Answer 2

在沒有磁盤膨脹的情況下切換到file_per_table的唯一（？）方法是

1. 轉儲數據。
2. 重新安裝（或以其他方式擺脫 ibdata1）。
3. 重新加載（打開 file_per_table）。