MySQL Delete 後，如何快速釋放磁盤空間

　　1、原由：收到運維需求須要清理兩張監控告警的日誌表，數據刪除以後，發現磁盤空間並未釋放。

　　2、分析：InnoDB 數據庫在使用 delete 進行刪除操做的時候，只會將已經刪除的數據標記爲刪除，並無把數據文件刪除，所以並不會完全的釋放空間。這些被刪除的數據會被保存在一個連接清單中，當有新數據寫入的時候，MySQL 會從新利用這些已刪除的空間進行再寫入。

　　3、解決：官方推薦可使用 OPTIMIZE TABLE 命令來優化表，該命令會從新利用未使用的空間，並整理數據文件的碎片。

　　語法以下：

OPTIMIZE [NO_WRITE_TO_BINLOG | LOCAL]
    TABLE tbl_name [, tbl_name] ...

　　註釋：OPTIMIZE TABLE 將從新組織表數據和相關索引數據的物理存儲空間，減小存儲空間並提升I/O訪問效率。對每一個表所作的影響取決於該表所使用的存儲引擎。該命令對視圖無效。

　　4、舉例說明：

　　1.查看優化前表佔用空間大小：

root@dbs00 13:58:46:monitor$ ls -alth
total 7.1G
-rw-r-----  1 mysql mysql 5.1G Nov 21 13:59 job_status_trace_log.ibd
-rw-r-----  1 mysql mysql 1.2G Nov 21 13:58 job_execution_log.ibd

　　2.使用OPTIMIZE 命令：

system@localhost 14:22:  [monitor]> optimize table job_execution_log;
+---------------------------+----------+----------+-------------------------------------------------------------------+
| Table                     | Op       | Msg_type | Msg_text                                                          |
+---------------------------+----------+----------+-------------------------------------------------------------------+
| monitor.job_execution_log | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| monitor.job_execution_log | optimize | status   | OK                                                                |
+---------------------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (1.09 sec)

system@localhost 14:23:  [monitor]> optimize table job_status_trace_log;
+------------------------------+----------+----------+-------------------------------------------------------------------+
| Table                        | Op       | Msg_type | Msg_text                                                          |
+------------------------------+----------+----------+-------------------------------------------------------------------+
| monitor.job_status_trace_log | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| monitor.job_status_trace_log | optimize | status   | OK                                                                |
+------------------------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (1.13 sec)

　　3.查看優化以後的磁盤空間佔用大小：

root@dpsvstadbs00 14:25:10:monitor$ ls -alth
total 868M
-rw-r-----  1 mysql mysql 368K Nov 21 14:26 job_exect_log.ibd
-rw-r-----  1 mysql mysql  17M Nov 21 14:26 job_trace_log.ibd

　  4.可使用SQL 語句查看錶佔用空間的大小（默認M爲單位）

system@localhost 17:52:  [monitor]> select table_name,(data_length+index_length)/1048576,table_rows from information_schema.tables where t
able_schema='monitor' and table_name='job_status_trace_log';

+----------------------+------------------------------------+------------+
| table_name           | (data_length+index_length)/1048576 | table_rows |
+----------------------+------------------------------------+------------+
| job_trace_log |                             9.0625 |      10401 |
+----------------------+------------------------------------+------------+
1 row in set (0.00 sec)

　　補充：

　　一、對於 InnoDB 存儲引擎 MySQL，OPTIMIZE 命令，將會被映射爲 ALTER TABLE  ... FORCE，並將重建表，更新索引統計信息，釋放未使用的索引空間，這就意味着在必定程度上 OPTIMIZE  操做會形成必定的表阻塞（具體能夠參加官網）。

　　二、OPTIMIZE 操做會鎖表，因此最好不要在高峯期使用。

 　  三、OPTIMIZE 操做至關於物理刪除，一旦刪除，恢復就很麻煩，因此最好使用邏輯刪除，也不要常常使用，每個月一次就夠了

官網地址：https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html