使用 percona 刪除列不會縮小表大小

我在 Aurora MySQL 5.7 中有一張表。表的分區很少，行數為 800m，權重為 2tb。最近我使用 percona 刪除了幾列。令人驚訝的是，桌子的大小沒有改變（在information_schema.tables.

percona 進行更改的方式是_<table_name>_new在原始表上使用帶有觸發器的新表。它創建一個具有相同 DDL 的空新表，執行我們希望的更改，並使用觸發器將所有內容複製到新表中以使其保持最新。一旦數據同步 - percona 重命名表並刪除舊表。所以表是從頭開始建構的（沒有鎖定）。

但是，執行後alter table optimize partition我看到大小縮小到 250gb。任何人都有解釋或知道我做錯了什麼？

pt 命令：

pt-online-schema-change --user $MYSQL_DBA_USER --password $MYSQL_DBA_PASS --host $MYSQL_WRITER D=db,t=table_data --alter "drop column a1, drop column a2"  --execute --max-load Threads_running=18446744073709551606 --critical-load Threads_running=18446744073709551606 --recursion-method=none

優化命令：

MySQL [(db)]> select table_rows,data_length/power(1024,3), index_length/power(1024,3),DATA_FREE/power(1024,3),AVG_ROW_LENGTH  from information_schema.tables where table_name='table_data';
+------------+---------------------------+----------------------------+-------------------------+----------------+
| table_rows | data_length/power(1024,3) | index_length/power(1024,3) | DATA_FREE/power(1024,3) | AVG_ROW_LENGTH |
+------------+---------------------------+----------------------------+-------------------------+----------------+
|  610884663 |        1847.7273712158203 |         202.40484619140625 |            0.0322265625 |           3247 |
+------------+---------------------------+----------------------------+-------------------------+----------------+
1 row in set (0.00 sec)


MySQL [db]> ALTER TABLE table_data OPTIMIZE PARTITION p20210601;
+---------------+----------+----------+---------------------------------------------------------------------------------------------+
| Table         | Op       | Msg_type | Msg_text                                                                                    |
+---------------+----------+----------+---------------------------------------------------------------------------------------------+
| db.table_data | optimize | note     | Table does not support optimize on partitions. All partitions will be rebuilt and analyzed. |
| db.table_data | optimize | status   | OK                                                                                          |
+------------------------+----------+----------+---------------------------------------------------------------------------------------------+
2 rows in set (5 hours 39 min 40.95 sec)

MySQL [db]>
MySQL [db]> select table_rows,data_length/power(1024,3), index_length/power(1024,3),DATA_FREE/power(1024,3),AVG_ROW_LENGTH  from information_schema.tables where table_name='table_data';


+------------+---------------------------+----------------------------+-------------------------+----------------+
| table_rows | data_length/power(1024,3) | index_length/power(1024,3) | DATA_FREE/power(1024,3) | AVG_ROW_LENGTH |
+------------+---------------------------+----------------------------+-------------------------+----------------+
|  736965899 |        104.25639343261719 |         155.98052978515625 |            0.0244140625 |            151 |
+------------+---------------------------+----------------------------+-------------------------+----------------+

由於多種原因，MySQL 在多種情況下不會將空閒空間釋放回作業系統。（共同點：MySQL 選擇速度而不是空間。）

在這種特殊情況下，有兩種選擇（儘管您可能沒有意識到這些細節）。

• 預設ALTER ... DROP COLUMN ...執行速度很快，只需更改表定義而不用擔心列佔用的空間。
• ALTER ... ALGORITHM=COPY ... DROP COLUMN ...複製表並重建索引。這很慢，但確實收回了可用空間。但它要慢得多，尤其是對於一張大桌子。 OPTIMIZE TABLE作為“副本”的一部分有效地完成了。

你被經典的電腦選擇困住了——速度與空間。

分區很少有用；你確定它有什麼好處嗎？

有一個“錯誤” OPTIMIZE PARTITION——它會重建每個分區，而不僅僅是您指定的分區。（要重建單個分區，請使用REORGANIZE。）

引用自：https://dba.stackexchange.com/questions/301972