大表 2 億行中的 InnoDB“漏洞”？
我有一個大約 2 億行的大型 MySql InnoDB 表。其中一列中有一些我真的不再需要的數據，所以我正在考慮刪除該列，或者將該列中的所有單元格設置為 NULL。
此列包含大約 300 個字元的文本值，因此通過刪除它，我將節省大約 300 字節 x 2 億行 = 60GB。
但是，這會在我的數據中留下很多“漏洞”嗎？MySql 能否在不進行某種碎片整理的情況下有效且高效地重用這個空間？或者這無關緊要，因為它是 InnoDB 並且在 SSD 驅動器上？
謝謝！
更新：該表總共有大約列，但其中大部分是 INT 值。這個文本欄位是迄今為止最大的。每行總共只佔用大約 4KB 的空間。
InnoDB 將數據（和索引）儲存在 16KB 塊中。
聽起來您將每行平均縮小了 7% (300/4K)。
如果收縮超過 50%，那麼 InnoDB 可能會注意到相鄰的半滿塊並將它們合併，從而釋放一些預期的節省。（一個塊是 16KB。）我只說“一些”，因為它不會積極地打包
UPDATEs或之後的塊DELETEs。如果您沒有完成
OPTIMIZE，未來的插入/刪除/更新，如果它們分散在桌子周圍，就會填補“漏洞”和/或導致阻塞合併。另一方面，如果主要活動是在PRIMARY KEY值的“末尾”添加新行，那麼後續的清理將不會發生，這OPTIMIZE將是可取的。給你帶來了多少
OPTIMIZE好處？性能可能變化很小。當然，您釋放了一些空間，但是，如果您沒有用完磁碟空間，那也沒關係。另一個問題…表空間。舊的預設設置是將所有表放入一個表空間（名為 的文件
ibdata1）。它會增長，但永遠不會縮小。任何釋放的塊都可用於未來的數據庫工作，但不會返回給作業系統。新的預設值 (
innodb_file_per_table) 有同樣的問題。但是，顯式重建OPTIMIZE表，並將釋放的空間還給作業系統。警告：在此過程中，您需要 2 倍的磁碟空間。所以，如果你的空間非常緊張，就會失敗。然而…OPTIMIZE
OPTIMIZE TABLE（對於 InnoDB）是“從 MySQL 5.6.17 開始就地執行。具有 FULLTEXT 索引的表不支持就地操作。該操作使用 INPLACE 算法，但不允許使用 ALGORITHM 和 LOCK 語法。”—— https ://dev.mysql.com/doc/refman/5.6/en/innodb-online-ddl-operations.html
這是依賴。表格的行格式可以在創建或更改時選擇。可能的選項有：
DYNAMIC、COMPACT和。REDUNDANT``COMPRESSED在您的情況下
COMPACT，磁碟佔用空間和處理成本之間有很好的平衡。此處提供了每種格式的非常詳細的說明：https ://dev.mysql.com/doc/refman/8.0/en/innodb-physical-record.html