1. 程式人生 > >資料庫優化---索引

資料庫優化---索引

4.1聚簇索引

聚簇索引的資料的物理存放順序與索引順序是一致的(查詢快,修改慢),即:只要索引是相鄰的,那麼對應的資料一定也是相鄰地存放在磁碟上的。如果主鍵不是自增id,那麼可以想象,它會幹些什麼,不斷地調整資料的實體地址、分頁,當然也有其他一些措施來減少這些操作,但卻無法徹底避免。但,如果是自增的,那就簡單了,它只需要一頁一頁地寫,索引結構相對緊湊,磁碟碎片少,效率也高。
聚簇索引不但在檢索上可以大大滴提高效率,在資料讀取上也一樣。比如:需要查詢f~t的所有單詞。
一個使用MyISAM的主索引,一個使用InnoDB的聚簇索引。兩種索引的B+Tree檢索時間一樣,但讀取時卻有了差異。
因為MyISAM的主索引並非聚簇索引,那麼他的資料的實體地址必然是凌亂的,拿到這些實體地址,按照合適的演算法進行I/O讀取,於是開始不停的尋道不停的旋轉。聚簇索引則只需一次I/O。
不過,如果涉及到大資料量的排序、全表掃描、count之類的操作的話,還是MyISAM佔優勢些,因為索引所佔空間小,這些操作是需要在記憶體中完成的。
鑑於聚簇索引的範圍查詢效率,很多人認為使用主鍵作為聚簇索引太多浪費,畢竟幾乎不會使用主鍵進行範圍查詢。但若再考慮到聚簇索引的儲存,就不好定論了。

建立聚簇索引的思想
①大多數表都應該有聚簇索引或使用分割槽來降低對錶尾頁的競爭,在一個高事務的環境中,對最後一頁的封鎖嚴重影響系統的吞吐量。
②在聚簇索引下,資料在物理上按順序排在資料頁上,重複值也排在一起,因而在那些包含範圍檢查(between、<、<=、>、>=)或使用group by或orderby的查詢時,一旦找到具有範圍中第一個鍵值的行,具有後續索引值的行保證物理上毗連在一起而不必進一步搜尋,避免了大範圍掃描,可以大大提高查詢速度。
③在一個頻繁發生插入操作的表上建立聚簇索引時,不要建在具有單調上升值的列(如IDENTITY)上,否則會經常引起封鎖衝突。
④在聚簇索引中不要包含經常修改的列,因為碼值修改後,資料行必須移動到新的位置。
⑤選擇聚簇索引應基於where子句和連線操作的型別。

聚簇索引的侯選列
①主鍵列,該列在where子句中使用並且插入是隨機的。
②按範圍存取的列,如pri_order > 100 and pri_order < 200。
③在group by或order by中使用的列。
④不經常修改的列。
⑤在連線操作中使用的列。