MySQL 索引壓縮碎片

MySQL 索引簡介

索引也叫「鍵」（key）,是存儲引擎用於快速找到記錄的一種數據結構。

索引對於良好的性能很是關鍵。數據量愈來愈大的時候，索引的重要性也會體現出來。

例以下面的sql：

Select * from user where userid=123;

若是沒有建立索引，此時查詢會全表掃描

若是在userid字段建立了索引，會根據索引來進行查詢。 

下面對於一樣的語句使用explain 進行執行計劃分析。 

下圖是未建立索引時的執行計劃，能夠看到type是all，key對應的內容爲空，說明沒有索引或者未命中索引。

  

下圖是建立了userid的索引的執行計劃，能夠看到type是ref，possible_keys 是推測的索引名稱，Key是索引名稱。這樣會減輕不少查詢的壓力。

 

 

MySQL 索引碎片

在數據表使用很長時間後，表上的B-Tree索引可能會碎片化，會下降查詢的效率。碎片化的索引可能會以不好或者無序的方式存儲在磁盤上。

以下圖，是未經優化的數據表的使用狀況。

執行語句：show table status like  'tables';，能夠獲得下圖：

  

字段解釋：

1. Data_length : 數據的大小。
2. Index_length: 索引的大小。
3. Data_free :數據在使用中的留存空間，若是常常刪改數據表，會形成大量的Data_free。

 

若是遇到上述狀況，須要及時清理碎片，以便清理碎片，提高效率。

在清理碎片前，查看數據表的文件大小，作個參考。以下圖：

 

能夠看到mysql 的數據文件通常有兩種：ibd，frm。

frm文件是數據表定義與格式。好比字段的類型。

Ibd文件是數據表的數據內容，主要是由數據內容與索引內容組成。能夠看到當前須要整理的數據表的ibd文件是240MB。

 

 

 

MySQL 壓縮索引碎片

執行命令：OPTIMIZE table tablename；能夠進行壓縮索引碎片。

須要注意的是，這個操做不該常常使用，以月左右的時間段爲基數進行一次清理便可。

在執行optimize命令時，會鎖定該表，相關操做會受到必定影響。 

查看壓縮後的參數，以下圖：

 

能夠看到data_free爲0，說明無留存空間了。Index_length 也少了不少。 

查看數據文件，一樣獲得了驗證：

 

 

能夠看到此表的ibd文件降到了160MB。較以前的240MB容量，釋放了不少空間。