最近有個上位機獲取下位機上報數據的項目，由于上報頻率比較頻繁且數據量大，導致數據增長過快，磁盤占用多。
明明已經執行了，可表文件的大小卻沒減小，令人費解
項目中使用MySQL作為數據庫，對于表來說，一般為表結構和表數據。表結構占用空間都是比較小的，一般都是表數據占用的空間。
當我們使用 刪除數據時，確實刪除了表中的數據記錄，但查看表文件大小卻沒什么變化。
MySQL數據結構
凡是使用過MySQL，對B+樹肯定是有所耳聞的，MySQL 中采用了 B+ 樹作為存儲數據的結構，也就是常說的索引組織表，并且數據是按照頁來存儲的。因此在刪除數據時，會有兩種情況：
表文件大小未更改和MySQL設計有關
比如想要刪除 R4 這條記錄：
直接將 R4 這條記錄標記為刪除，稱為可復用的位置。如果之后要插入 ID 在 300 到 700 間的記錄時，就會復用該位置。由此可見，磁盤文件的大小并不會減少。
通用刪除整頁數據也將記錄標記刪除，數據就復用用該位置，與刪除默寫記錄不同的是刪除文件后空間沒釋放，刪除整頁記錄，當后來插入的數據不在原來的范圍時，都可以復用位置，而如果只是刪除默寫記錄，是需要插入數據符合刪除記錄位置的時候才能復用。
因此，無論是數據行的刪除還是數據頁的刪除刪除文件后空間沒釋放，都是將其標記為刪除的狀態，用于復用，所以文件并不會減小。
那怎么才能讓表大小變小
只是將數據標識位刪除，并沒有整理數據文件，當插入新數據后，會再次使用這些被置為刪除標識的記錄空間，可以使用 TABLE來回收未使用的空間，并整理數據文件的碎片。
注意： TABLE只對, BDB和表起作用。
另外，也可以執行通過ALTER TABLE重建表
有人會問 TABLE和ALTER TABLE有什么區別？
alter table t = （也就是），而 table t 等于+
DDL
最后，再說一下 DDL，dba的日常工作肯定有一項是ddl變更，ddl變更會鎖表，這個可以說是dba心中永遠的痛，特別是執行ddl變更，導致庫上大量線程處于“ for meta data lock”狀態的時候。因此在 5.6 版本后引入了 DDL。
DDL推出以前，執行ddl主要有兩種方式copy方式和方式，方式又稱為(fast index )。相對于copy方式，方式不拷貝數據，因此較快。但是這種方式僅支持添加、刪除索引兩種方式，而且與copy方式一樣需要全程鎖表，實用性不是很強。方式與前兩種方式相比，不僅可以讀，還可以支持寫操作。
執行 DDL語句的時候，使用和LOCK關鍵字，這兩個關鍵字在我們的DDL語句的最后面，用逗號隔開即可。示例如下：
ALTERTABLE tbl_name ADDCOLUMN col_name col_type, ALGORITHM=INPLACE, LOCK=NONE;選項
LOCK選項
執行DDL操作時，選項可以不指定，這時候MySQL按照、、COPY的順序自動選擇合適的模式。也可以指定=，也是同樣的效果。如果指定了選項，但不支持的話，會直接報錯。
TABLE 和ALTER TABLE 表名 =都支持Oline DDL，但依舊建議在業務訪問量低的時候使用
總結
刪除數據時，其實對應的數據行并不是真正的刪除，僅僅是將其標記成可復用的狀態，所以表空間不會變小。
可以重建表的方式，快速將數據后的表變?。?TABLE 或ALTER TABLE），在 5.6 版本后，創建表已經支持 的操作，但最好是在業務低峰時使用。