片段產生的原因
(1)表的儲存會出現片段化,每當刪除了一行內容,該段空間就會變為空白、被留空,而在一段時間內的大量刪除操作,會使這種留空的空間變得比儲存列表內容所使用的空間更大;
(2)當執行插入操作時,MySQL會嘗試使用空白空間,但如果某個空白空間一直沒有被大小合適的資料佔用,仍然無法將其徹底佔用,就形成了片段;
(3)當MySQL對資料進行掃描時,它掃描的對象實際是列表的容量需求上限,也就是資料被寫入的地區中處於峰值位置的部分;
例如:一個表有1萬行,每行10位元組,會佔用10萬位元組儲存空間,執行刪除操作,只留一行,實際內容只剩下10位元組,但MySQL在讀取時,仍看做是10萬位元組的表進行處理,所以,片段越多,就會越來越影響查詢效能。
查看錶片段大小
(1)查看某個表的片段大小
mysql> SHOW TABLE STATUS LIKE '表名';
結果中’Data_free’列的值就是片段大小
MySQL 清除資料表空間片段(2)列出所有已經產生片段的表
mysql> select table_schema db, table_name, data_free, engine
from information_schema.tables
where table_schema not in ('information_schema', 'mysql') and data_free > 0;
清除表片段(對於不同的儲存引擎整理片段的方式不一樣)
可以有以下方式:
mysql> show table status from test like 'testusers'\G
*************************** 1. row ***************************
....
Rows: 3
Avg_row_length: 45
Data_free: 40
.....
因為在中間刪除,所以留下了空白
mysql> optimize table testusers;
+----------------+----------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+----------------+----------+----------+----------+
| test.testusers | optimize | status | OK |
+----------------+----------+----------+----------+
1 row in set (0.00 sec)
mysql> show table status from test like 'testusers'\G
*************************** 1. row ***************************
...
Rows: 3
Avg_row_length: 32
Data_length: 96
Data_free: 0
1 row in set (0.00 sec)
在optimize後,Data_free已經變為0.片段資料被清除。
同樣還可以用以下方式,效果和optimize一樣
./bin/mysqlcheck -uroot -proot --socket=./tmp/mysql.sock -o test testusers
(2)InnoDB表
mysql> alter table 表名 engine=InnoDB
innodb
對於innodb 使用optimize和mysqlcheck都不起作用,可以如下進行
對於小表的話直接用ALTER TABLE table_name ;回收資料表空間,對於大表就不能直接採用這種方式,因為會造成長時間的鎖表。可以採用建立錶轉移資料,然後刪除舊錶的形式,然後再重新命名表。
Engine不同,OPTIMIZE 的操作也不一樣的,MyISAM 因為索引和資料是分開的,所以 OPTIMIZE 可以整理資料檔案,並重排索引.
OPTIMIZE 操作會暫時鎖住表,而且資料量越大,耗費的時間也越長,它畢竟不是簡單查詢操作.所以把 Optimize 命令放在程式中是不妥當的,不管設定的命中率多低,當訪問量增大的時候,整體命中率也會上升,這樣肯定會對程式的運行效率造成很大影響.比較好的方式就是做個shell,定期檢查mysql中 information_schema.TABLES欄位,查看 DATA_FREE 欄位,大於0話,就表示有片段
建議
清除片段操作會暫時鎖表,資料量越大,耗費的時間越長,可以做個指令碼,定期在訪問低穀時間執行,例如每周三淩晨,檢查DATA_FREE欄位,大於自己認為的警戒值的話,就清理一次。