首頁  >  文章  >  資料庫  >  Mysql系列(五)索引功能

Mysql系列(五)索引功能

黄舟
黄舟原創
2017-01-22 16:41:56769瀏覽

索引是一種特殊的檔案(InnoDB 資料表上的索引是表空間的一個組成部分),它們包含著資料表裡所有記錄的引用指標。索引不是萬能的,索引可以加快資料檢索操作,但會使資料修改操作變慢。每修改資料記錄,索引就必須刷新一次。為了在某種程度上彌補這個缺陷,許多 SQL 指令都有一個 DELAY_KEY_WRITE 項目。這個選項的作用是暫時制止 MySQL 在該指令每插入一筆新記錄和每修改一筆現有之後立刻對索引進行刷新,對索引的刷新將等到全部記錄插入/修改完畢之後再進行。在需要把許多新記錄插入某個資料表的場合,DELAY_KEY_WRITE 選項的作用將非常明顯。另外,索引也會在硬碟上佔用相當大的空間。因此應該只為最經常查詢和最經常排序的資料列建立索引。請注意,如果某個資料列包含許多重複的內容,為它建立索引就沒有太大的實際效果。

從理論上講,完全可以為資料表裡的每個欄位分別建立索引,但 MySQL 把同一個資料表裡的索引總數限制為16個。

1. InnoDB 資料表的索引

與 InnoDB資料表相比,在 InnoDB 資料表上,索引對 InnoDB 資料表的重要性大得多。在 InnoDB 資料表上,索引不僅會在搜尋資料記錄時發揮作用,也是資料行級鎖定機制的苊、基礎。 「資料行級鎖定」的意思是指在事務操作的執行過程中鎖定正在被處理的個別記錄,不讓其他使用者進行存取。這種鎖定將影響(但不限於)SELECT、LOCKINSHAREMODE、SELECT、FORUPDATE 命令以及 INSERT、UPDATE 和 DELETE 命令。出於效率方面的考慮,InnoDB 資料表的資料行級鎖定實際上發生在它們的索引上,而不是資料表本身。顯然,資料行級鎖定機制只有在相關的資料表有一個合適的索引可供鎖定的時候才能發揮效力。

2.限制

如果 WHERE 子句的查詢條件裡有不等號(WHERE coloum !=),MySQL 將無法使用索引。類似地,如果 WHERE 子句的查詢條件裡使用了函式(WHERE DAY(column)=),MySQL 也將無法使用索引。在 JOIN 操作中(需要從多個資料表提取資料時),MySQL 只有在主鍵和外鍵的資料類型相同時才能使用索引。

如果 WHERE 子句的查詢條件裡使用比較操作符 LIKE 和 REGEXP,MySQL 只有在搜尋模板的第一個字元不是通配符的情況下才能使用索引。比方說,如果查詢條件是 LIKE 'abc%‘,MySQL 將使用索引;如果查詢條件是 LIKE '%abc’,MySQL 將不使用索引。

在 ORDER BY 操作中,MySQL 只有在排序條件不是一個查詢條件表達式的情況下才使用索引。 (雖然如此,在涉及多個資料表查詢裡,即使有索引可用,那些索引在加快 ORDER BY 方面也沒什麼作用)。如果某個資料列裡包含許多重複的值,就算為它建立了索引也不會有很好的效果。比如說,如果某個資料列裡包含的淨是些諸如 “0/1” 或 “Y/N” 等值,就沒有必要為它建立一個索引。

索引類別

1.普通索引

普通索引(由關鍵字 KEY 或 INDEX 定義的索引)的唯一任務是加快對資料的存取速度。因此,應該只為那些最常出現在查詢條件(WHERE column =)或排序條件(ORDER BY column)中的資料列建立索引。只要有可能,就應該選擇一個資料最整齊、最緊湊的資料列(如一個整數類型的資料列)來建立索引。

2.唯一索引

普通索引允許被索引的資料列包含重複的值。比如說,因為人有可能同名,所以同一個姓名在同一個「員工個人資料」資料表裡可能出現兩次或更多次。

如果能確定某個資料列將只包含彼此各不相同的值,在為這個資料列建立索引的時候就應該用關鍵字UNIQUE 把它定義為一個唯一索引。這麼做的好處:一是簡化了MySQL 對這個索引的管理工作,這個索引也因此而變得更有效率;二是MySQL 會在有新記錄插入資料表時,自動檢查新記錄的這個欄位的值是否已經在某個記錄的這個欄位裡出現過了;如果是,MySQL 將拒絕插入那筆新記錄。也就是說,唯一索引可以保證資料記錄的唯一性。事實上,在許多場合,人們創建唯一索引的目的往往不是為了提高存取速度,而只是為了避免資料重複出現。

3.主索引

在前面已經反覆多次強調:必須為主鍵字段創建一個索引,這個索引就是所謂的「主索引」。主索引與唯一索引的唯一差異是:前者在定義時使用的關鍵字是 PRIMARY 而不是 UNIQUE。

4.外鍵索引

如果為某個外鍵欄位定義了一個外鍵約束條件,MySQL 就會定義一個內部索引來幫助自己以最有效率的方式去管理和使用外鍵約束條件。

5.複合索引

索引可以覆寫多個資料列,如像 INDEX (columnA, columnB) 索引。這種索引的特點是 MySQL 可以選擇性地使用一個這樣的索引。如果查詢操作只需要用到 columnA 資料列上的一個索引,就可以使用複合索引 INDEX(columnA, columnB)。不過,這種用法僅適用於在複合索引中排列在前的資料列組合。比方說,INDEX (A,B,C) 可以當作 A 或 (A,B) 的索引來使用,但不能當做 B、C 或 (B,C) 的索引來使用。

索引長度

在為CHAR 和VARCHAR 類型的資料列定義索引時,可以把索引的長度限制為一個給定的字元數(這個數字必須小於這個欄位所允許的最大字元數) 。這麼做的好處是可以產生一個尺寸比較小、檢索速度卻比較快的索引檔。在絕大多數應用程式裡,資料庫中的字串資料大都以各種各樣的名字為主,把索引的長度設定為10~15 個字元已經足以把搜尋範圍縮小到很少的幾條資料記錄了。在為BLOB 和TEXT 類型的資料列建立索引時,必須對索引的長度做出限制;MySQL 所允許的最大索引全文索引文字欄位上的普通索引只能加快對出現在欄位內容最前面的字串(也就是字段內容開頭的字元)進行檢索操作。如果字段裡存放的是由幾個、甚至是多個單字構成的較大段文字,普通索引就沒什麼作用了。這種檢索往往以的形式出現,這對 MySQL 來說很複雜,如果需要處理的資料量很大,回應時間就會很長。

這類場合正是全文索引(full-textindex)可以大顯身手的地方。在產生這種類型的索引時,MySQL 將把在文字中出現的所有單字建立為一份清單,查詢操作將根據這份清單去檢索相關的資料記錄。全文索引即可以隨資料表一同創建,也可以等日後有必要時再使用下面這條指令添加:

ALTER TABLE tablename ADD FULLTEXT(column1,column2)有了全文索引,就可以用SELECT 查詢指令去檢索那些包含著一個或多個給定單字的資料記錄了。以下是這類查詢指令的基本語法:

SELECT * FROM tablename

WHERE MATCH (column1,column2) AGAINST('word1','word2','word3')

這命令將會在上面指令欄位裡有word1、word2 和word3 的資料記錄全部查詢出來。

註解:InnoDB 資料表不支援全文索引。

查詢和索引

只有當資料庫裡已經有了足夠多的測試資料時,它的效能測試結果才有實際參考價值。如果在測試資料庫裡只有幾百筆資料記錄,它們往往在執行完第一個查詢指令之後就被全部載入到記憶體裡,這將使後續的查詢指令都執行得非常快--不管有沒有使用索引。只有當資料庫裡的記錄超過了 1000 條、資料總量也超過了 MySQL 伺服器上的記憶體總量時,資料庫的效能測試結果才有意義。

在不確定應該在哪些資料列上建立索引的時候,人們從 EXPLAIN SELECT 指令那裡往往可以獲得一些幫助。這其實只是簡單地為一個普通的 SELECT 指令加一個 EXPLAIN 關鍵字當作字首。有了這個關鍵字,MySQL 將不是去執行那條 SELECT 指令,而是去對它進行分析。 MySQL 將以表格的形式列出查詢的執行過程和用到的索引等資訊。

在 EXPLAIN 指令的輸出結果裡,第1列是從資料庫讀取的資料表的名字,它們依被讀取的先後順序排列。 type列指定了本資料表與其它資料表之間的關聯關係(JOIN)。在各種類型的關聯關係當中,效率最高的是system,然後依序是const、eq_ref、ref、range、index 和All(All 的意思是:對應於上一層資料表裡的每筆記錄,這個數據表裡的所有記錄都必須讀取一次-這種情況往往可以用一個索引來避免)。

possible_keys 資料列給出了 MySQL 在搜尋資料記錄時可選用的各個索引。 key 資料列是 MySQL 實際選用的索引,這個索引以位元組計算的長度在 key_len 資料列裡給出。比如說,對於一個 INTEGER 資料列的索引,這個位元組長度將會是4。如果用到了複合索引,在 key_len 資料列裡還可以看到 MySQL 具體使用了它的哪些部分。作為一般規律,key_len 資料列裡的值越小越好。

ref 資料列給出了關聯關係中另一個資料表裡的資料列的名稱。 row 資料列是 MySQL 在執行這個查詢時預期會從這個資料表裡讀出的資料行的個數。 row 資料列裡的所有數字的乘積可以大致了解這個查詢需要處理多少組合。

最後,extra 資料列提供了與 JOIN 操作有關的更多信息,比如說,如果 MySQL 在執行這個查詢時必須創建一個臨時資料表,就會在 extra 列中看到 usingtemporary 字樣。

以上就是Mysql系列(五)索引功能的內容,更多相關內容請關注PHP中文網(www.php.cn)!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn