釋放 MySQL 5.6.20 中的空間 - InnoDB

Question

首先，不是數據庫人。 這就是問題所在，數據庫的數據驅動器已滿 96%。 在 my.cnf 中有一行包含以下內容，（由於空間僅顯示部分）

innodb_data_file_path=nmsdata1:4000M;nmsdata2:4000M; 

上升到

nmsdata18:4000M:autoextend

因此，在存儲文件的文件夾中，文件 1-17 的大小為 4gb，截至今天，文件 18 的大小為 136gb。

我繼承了這個系統，它沒有供應商支持或太多文檔。 我可以看到有幾張桌子真的很大

Table_name                             NumRows              Data Length
----------                             -------              -----------
pmdata                                 100964536            14199980032
fault                                  310864227            63437946880
event                                  385910821            107896160256

我知道發生了大量的寫入，應該有一個 cron 作業告訴它只保留最近 3 個月的數據，但我擔心數據庫是碎片化的，沒有釋放空間供使用。

所以我的任務是釋放數據庫中的空間，這樣驅動器就不會被填滿。

Answer 1

這是 innodb 的一個弱點：表空間從不收縮。 它們會增長，即使您對表進行“碎片整理”，它們也會在內部寫入表空間的另一部分，從而使更多的表空間“空閑”以供其他數據使用，但磁盤上文件的大小不會縮小.

即使您 DROP TABLE，也不會為驅動器釋放空間。

這一直是 InnoDB 的痛點： https://bugs.mysql.com/bug.php?id=1341 (reported circa.)

解決方法是在您的配置中使用innodb_file_per_table=1 ，這樣每個表都有自己的表空間。 然后，當您使用OPTIMIZE TABLE <tablename>時，它會以更高效、更緊湊的內部布局將數據復制到新表空間來進行碎片整理，然后丟棄碎片。

但在你的情況下，這有一個大問題。 即使您在設置innodb_file_per_table=1后優化表，它們的數據也會被復制到新的表空間中，但這仍然不會縮小或刪除舊的多表表空間，例如nmsdata1到 18。它們仍然很大，但是“空的。”

我要說的是你完蛋了。 沒有辦法縮小這些表空間，而且由於磁盤空間已滿，因此也無法重構它們。

這是我要做的：構建一個新的 MySQL 服務器。 確保配置innodb_file_per_table=1 。 還要配置數據文件路徑的默認值： innodb_data_file_path=ibdata1:12M:autoextend 。 這將使中央表空間從一開始就變小。 我們將避免用數據擴展它。

然后導出您當前數據庫服務器的轉儲，所有這些。 將其導入您的新 MySQL 服務器。 它將遵循 file-per-table 設置，並且數據將創建並填充新的表空間，每個表一個。

鑒於您對數據增長的了解，這也是構建具有更大存儲空間的新服務器的機會。

導入這么多數據需要很長時間。 多長時間取決於您的服務器性能規格，但至少需要幾個小時。 也許幾天。 如果您在導入時原始數據庫仍在占用流量，這將是一個問題。

解決方案是使用復制，因此您的新服務器可以從創建轉儲的位置“趕上”到數據庫的當前 state。 此過程已記錄在案，但對於不是數據庫專業人士的人來說，這可能是一個相當長的學習曲線，正如您所說： https://dev.mysql.com/doc/refman/8.0/en/replication-howto。 html

您可能應該找一位知道如何完成這項工作的顧問。