為什麼delete表資料，磁碟空間卻還是被佔用

最近有個上位機獲取下位機上報資料的專案，由於上報頻率比較頻繁且資料量大，導致資料增長過快，磁碟佔用多。

為了節約成本，定期進行資料備份，並透過delete刪除表記錄。

明明已經執行了delete，可表文件的大小卻沒減小，令人費解

專案中使用Mysql作為資料庫，對於表來說，一般為表結構和表資料。表結構佔用空間都是比較小的，一般都是表資料佔用的空間。

當我們使用 delete刪除資料時，確實刪除了表中的資料記錄，但查看錶檔案大小卻沒什麼變化。

Mysql資料結構

凡是使用過mysql，對B+樹肯定是有所耳聞的，MySQL InnoDB 中採用了 B+ 樹作為儲存資料的結構，也就是常說的索引組織表，並且資料時按照頁來儲存的。因此在刪除資料時，會有兩種情況：

刪除資料頁中的某些記錄

刪除整個資料頁的內容

表文件大小未更改和mysql設計有關

比如想要刪除 R4 這條記錄：

InnoDB 直接將 R4 這條記錄標記為刪除，稱為可複用的位置。如果之後要插入 ID 在 300 到 700 間的記錄時，就會複用該位置。

由此可見，磁碟檔案的大小並不會減少。

通用刪除整頁資料也將記錄標記刪除，資料就複用用該位置，與刪除默寫記錄不同的是，刪除整頁記錄，當後來插入的資料不在原來的範圍時，都可以複用位置，而如果只是刪除默寫記錄，是需要插入資料符合刪除記錄位置的時候才能複用。

因此，無論是資料行的刪除還是資料頁的刪除，都是將其標記為刪除的狀態，用於複用，所以檔案並不會減小。

那怎麼才能讓表大小變小

DELETE只是將資料標識位刪除，並沒有整理資料檔案，當插入新資料後，會再次使用這些被置為刪除標識的記錄空間，可以使用OPTIMIZE TABLE來回收未使用的空間，並整理資料檔案的碎片。

注意：OPTIMIZE TABLE只對MyISAM， BDB和InnoDB表起作用。

另外，也可以執行透過ALTER TABLE重建表

有人會問OPTIMIZE TABLE和ALTER TABLE有什麼區別？

alter table t engine = InnoDB（也就是recreate），而optimize table t 等於recreate+analyze

Online DDL

最後，再說一下Online DDL，dba的日常工作肯定有一項是ddl變更，ddl變更會鎖表，這個可以說是dba心中永遠的痛，特別是執行ddl變更，導致庫上大量執行緒處於“Waiting for meta data lock”狀態的時候。因此在 5。6 版本後引入了 Online DDL。

Online DDL推出以前，執行ddl主要有兩種方式copy方式和inplace方式，inplace方式又稱為（fast index creation）。相對於copy方式，inplace方式不複製資料，因此較快。但是這種方式僅支援新增、刪除索引兩種方式，而且與copy方式一樣需要全程鎖表，實用性不是很強。Online方式與前兩種方式相比，不僅可以讀，還可以支援寫操作。

執行online DDL語句的時候，使用ALGORITHM和LOCK關鍵字，這兩個關鍵字在我們的DDL語句的最後面，用逗號隔開即可。示例如下：

ALTER TABLE tbl_name ADD COLUMN col_name col_type， ALGORITHM=INPLACE， LOCK=NONE；

ALGORITHM選項

INPLACE：替換：直接在原表上面執行DDL的操作。

COPY：複製：使用一種臨時表的方式，克隆出一個臨時表，在臨時表上執行DDL，然後再把資料匯入到臨時表中，在重新命名等。這期間需要多出一倍的磁碟空間來支撐這樣的操作。執行期間，表不允許DML的操作。

DEFAULT：預設方式，有MySQL自己選擇，優先使用INPLACE的方式。

LOCK選項

SHARE：共享鎖，執行DDL的表可以讀，但是不可以寫。

NONE：沒有任何限制，執行DDL的表可讀可寫。

EXCLUSIVE：排它鎖，執行DDL的表不可以讀，也不可以寫。

DEFAULT：預設值，也就是在DDL語句中不指定LOCK子句的時候使用的預設值。如果指定LOCK的值為DEFAULT，那就是交給MySQL子句去覺得鎖還是不鎖表。不建議使用，如果你確定你的DDL語句不會鎖表，你可以不指定lock或者指定它的值為default，否則建議指定它的鎖型別。

執行DDL操作時，ALGORITHM選項可以不指定，這時候MySQL按照INSTANT、INPLACE、COPY的順序自動選擇合適的模式。也可以指定ALGORITHM=DEFAULT，也是同樣的效果。如果指定了ALGORITHM選項，但不支援的話，會直接報錯。