mysql索引與優化

寫在前面：索引對查詢的速度有着相當重要的影響，理解索引也是進行數據庫性能調優的起點。考慮以下狀況，假設數據庫中一個表有10^6條記錄，DBMS的頁面大小爲4K，並存儲100條記錄。若是沒有索引，查詢將對整個表進行掃描，最壞的狀況下，若是全部數據頁都不在內存，須要讀取10^4個頁面，若是這10^4個頁面在磁盤上隨機分佈，須要進行10^4次I/O，假設磁盤每次I/O時間爲10ms(忽略數據傳輸時間)，則總共須要100s(但實際上要好不少不少)。若是對之創建B-Tree索引，則只須要進行log100(10^6)=3次頁面讀取，最壞狀況下耗時30ms。這就是索引帶來的效果，不少時候，當你的應用程序進行SQL查詢速度很慢時，應該想一想是否能夠建索引。進入正題： 第二章、索引與優化 一、選擇索引的數據類型 MySQL支持不少數據類型，選擇合適的數據類型存儲數據對性能有很大的影響。一般來講，能夠遵循如下一些指導原則： (1)越小的數據類型一般更好：越小的數據類型一般在磁盤、內存和CPU緩存中都須要更少的空間，處理起來更快。 (2)簡單的數據類型更好：整型數據比起字符，處理開銷更小，由於字符串的比較更復雜。在MySQL中，應該用內置的日期和時間數據類型，而不是用字符串來存儲時間；以及用整型數據類型存儲IP地址。 (3)儘可能避免NULL：應該指定列爲NOT NULL，除非你想存儲NULL。在MySQL中，含有空值的列很難進行查詢優化，由於它們使得索引、索引的統計信息以及比較運算更加複雜。你應該用0、一個特殊的值或者一個空串代替空值。 1.一、選擇標識符 選擇合適的標識符是很是重要的。選擇時不只應該考慮存儲類型，並且應該考慮MySQL是怎樣進行運算和比較的。一旦選定數據類型，應該保證全部相關的表都使用相同的數據類型。 (1)    整型：一般是做爲標識符的最好選擇，由於能夠更快的處理，並且能夠設置爲AUTO_INCREMENT。 (2)    字符串：儘可能避免使用字符串做爲標識符，它們消耗更好的空間，處理起來也較慢。並且，一般來講，字符串都是隨機的，因此它們在索引中的位置也是隨機的，這會致使頁面分裂、隨機訪問磁盤，聚簇索引分裂（對於使用聚簇索引的存儲引擎）。 二、索引入門 對於任何DBMS，索引都是進行優化的最主要的因素。對於少許的數據，沒有合適的索引影響不是很大，可是，當隨着數據量的增長，性能會急劇降低。 若是對多列進行索引(組合索引)，列的順序很是重要，MySQL僅能對索引最左邊的前綴進行有效的查找。例如： 假設存在組合索引it1c1c2(c1,c2)，查詢語句select * from t1 where c1=1 and c2=2可以使用該索引。查詢語句select * from t1 where c1=1也可以使用該索引。可是，查詢語句select * from t1 where c2=2不可以使用該索引，由於沒有組合索引的引導列，即，要想使用c2列進行查找，必需出現c1等於某值。 2.一、索引的類型 索引是在存儲引擎中實現的，而不是在服務器層中實現的。因此，每種存儲引擎的索引都不必定徹底相同，並非全部的存儲引擎都支持全部的索引類型。 2.1.一、B-Tree索引 假設有以下一個表： CREATE TABLE People (    last_name varchar(50)    not null,    first_name varchar(50)    not null,    dob        date           not null,    gender     enum('m', 'f') not null,    key(last_name, first_name, dob) ); 其索引包含表中每一行的last_name、first_name和dob列。其結構大體以下： 索引存儲的值按索引列中的順序排列。能夠利用B-Tree索引進行全關鍵字、關鍵字範圍和關鍵字前綴查詢，固然，若是想使用索引，你必須保證按索引的最左邊前綴(leftmost prefix of the index)來進行查詢。 (1)匹配全值(Match the full value)：對索引中的全部列都指定具體的值。例如，上圖中索引能夠幫助你查找出生於1960-01-01的Cuba Allen。 (2)匹配最左前綴(Match a leftmost prefix)：你能夠利用索引查找last name爲Allen的人，僅僅使用索引中的第1列。 (3)匹配列前綴(Match a column prefix)：例如，你能夠利用索引查找last name以J開始的人，這僅僅使用索引中的第1列。 (4)匹配值的範圍查詢(Match a range of values)：能夠利用索引查找last name在Allen和Barrymore之間的人，僅僅使用索引中第1列。 (5)匹配部分精確而其它部分進行範圍匹配(Match one part exactly and match a range on another part)：能夠利用索引查找last name爲Allen，而first name以字母K開始的人。 (6)僅對索引進行查詢(Index-only queries)：若是查詢的列都位於索引中，則不須要讀取元組的值。 因爲B-樹中的節點都是順序存儲的，因此能夠利用索引進行查找(找某些值)，也能夠對查詢結果進行ORDER BY。固然，使用B-tree索引有如下一些限制： (1) 查詢必須從索引的最左邊的列開始。關於這點已經提了不少遍了。例如你不能利用索引查找在某一天出生的人。 (2) 不能跳過某一索引列。例如，你不能利用索引查找last name爲Smith且出生於某一天的人。 (3) 存儲引擎不能使用索引中範圍條件右邊的列。例如，若是你的查詢語句爲WHERE last_name="Smith" AND first_name LIKE 'J%' AND dob='1976-12-23'，則該查詢只會使用索引中的前兩列，由於LIKE是範圍查詢。 2.1.二、Hash索引 MySQL中，只有Memory存儲引擎顯示支持hash索引，是Memory表的默認索引類型，儘管Memory表也可使用B-Tree索引。Memory存儲引擎支持非惟一hash索引，這在數據庫領域是罕見的，若是多個值有相同的hash code，索引把它們的行指針用鏈表保存到同一個hash表項中。 假設建立以下一個表： CREATE TABLE testhash (    fname VARCHAR(50) NOT NULL,    lname VARCHAR(50) NOT NULL,    KEY USING HASH(fname) ) ENGINE=MEMORY; 包含的數據以下： 假設索引使用hash函數f( )，以下： f('Arjen') = 2323 f('Baron') = 7437 f('Peter') = 8784 f('Vadim') = 2458 此時，索引的結構大概以下： Slots是有序的，可是記錄不是有序的。當你執行 mysql> SELECT lname FROM testhash WHERE fname='Peter'; MySQL會計算’Peter’的hash值，而後經過它來查詢索引的行指針。由於f('Peter') = 8784，MySQL會在索引中查找8784，獲得指向記錄3的指針。 由於索引本身僅僅存儲很短的值，因此，索引很是緊湊。Hash值不取決於列的數據類型，一個TINYINT列的索引與一個長字符串列的索引同樣大。 Hash索引有如下一些限制： (1)因爲索引僅包含hash code和記錄指針，因此，MySQL不能經過使用索引避免讀取記錄。可是訪問內存中的記錄是很是迅速的，不會對性形成太大的影響。 (2)不能使用hash索引排序。 (3)Hash索引不支持鍵的部分匹配，由於是經過整個索引值來計算hash值的。 (4)Hash索引只支持等值比較，例如使用=，IN( )和<=>。對於WHERE price>100並不能加速查詢。 2.1.三、空間(R-Tree)索引 MyISAM支持空間索引，主要用於地理空間數據類型，例如GEOMETRY。 2.1.四、全文(Full-text)索引 全文索引是MyISAM的一個特殊索引類型，主要用於全文檢索。 三、高性能的索引策略 3.一、聚簇索引(Clustered Indexes) 聚簇索引保證關鍵字的值相近的元組存儲的物理位置也相同（因此字符串類型不宜創建聚簇索引，特別是隨機字符串，會使得系統進行大量的移動操做），且一個表只能有一個聚簇索引。由於由存儲引擎實現索引，因此，並非全部的引擎都支持聚簇索引。目前，只有solidDB和InnoDB支持。 聚簇索引的結構大體以下： 注：葉子頁面包含完整的元組，而內節點頁面僅包含索引的列(索引的列爲整型)。一些DBMS容許用戶指定聚簇索引，可是MySQL的存儲引擎到目前爲止都不支持。InnoDB對主鍵創建聚簇索引。若是你不指定主鍵，InnoDB會用一個具備惟一且非空值的索引來代替。若是不存在這樣的索引，InnoDB會定義一個隱藏的主鍵，而後對其創建聚簇索引。通常來講，DBMS都會以聚簇索引的形式來存儲實際的數據，它是其它二級索引的基礎。 3.1.一、InnoDB和MyISAM的數據佈局的比較 爲了更加理解聚簇索引和非聚簇索引，或者primary索引和second索引(MyISAM不支持聚簇索引)，來比較一下InnoDB和MyISAM的數據佈局，對於以下表： CREATE TABLE layout_test (    col1 int NOT NULL,    col2 int NOT NULL,    PRIMARY KEY(col1),    KEY(col2) ); 假設主鍵的值位於1---10,000之間，且按隨機順序插入，而後用OPTIMIZE TABLE進行優化。col2隨機賦予1---100之間的值，因此會存在許多重複的值。 (1)    MyISAM的數據佈局 其佈局十分簡單，MyISAM按照插入的順序在磁盤上存儲數據，以下： 注：左邊爲行號(row number)，從0開始。由於元組的大小固定，因此MyISAM能夠很容易的從表的開始位置找到某一字節的位置。 據些創建的primary key的索引結構大體以下： 注：MyISAM不支持聚簇索引，索引中每個葉子節點僅僅包含行號(row number)，且葉子節點按照col1的順序存儲。 來看看col2的索引結構： 實際上，在MyISAM中，primary key和其它索引沒有什麼區別。Primary key僅僅只是一個叫作PRIMARY的惟一，非空的索引而已。 (2)    InnoDB的數據佈局 InnoDB按聚簇索引的形式存儲數據，因此它的數據佈局有着很大的不一樣。它存儲表的結構大體以下： 注：聚簇索引中的每一個葉子節點包含primary key的值，事務ID和回滾指針(rollback pointer)——用於事務和MVCC，和餘下的列(如col2)。 相對於MyISAM，二級索引與聚簇索引有很大的不一樣。InnoDB的二級索引的葉子包含primary key的值，而不是行指針(row pointers)，這減少了移動數據或者數據頁面分裂時維護二級索引的開銷，由於InnoDB不須要更新索引的行指針。其結構大體以下： 聚簇索引和非聚簇索引表的對比： 3.1.二、按primary key的順序插入行(InnoDB) 若是你用InnoDB，並且不須要特殊的聚簇索引，一個好的作法就是使用代理主鍵(surrogate key)——獨立於你的應用中的數據。最簡單的作法就是使用一個AUTO_INCREMENT的列，這會保證記錄按照順序插入，並且能提升使用primary key進行鏈接的查詢的性能。應該儘可能避免隨機的聚簇主鍵，例如，字符串主鍵就是一個很差的選擇，它使得插入操做變得隨機。 3.二、覆蓋索引(Covering Indexes) 若是索引包含知足查詢的全部數據，就稱爲覆蓋索引。覆蓋索引是一種很是強大的工具，能大大提升查詢性能。只須要讀取索引而不用讀取數據有如下一些優勢： (1)索引項一般比記錄要小，因此MySQL訪問更少的數據； (2)索引都按值的大小順序存儲，相對於隨機訪問記錄，須要更少的I/O； (3)大多數據引擎能更好的緩存索引。好比MyISAM只緩存索引。 (4)覆蓋索引對於InnoDB表尤爲有用，由於InnoDB使用匯集索引組織數據，若是二級索引中包含查詢所需的數據，就再也不須要在彙集索引中查找了。 覆蓋索引不能是任何索引，只有B-TREE索引存儲相應的值。並且不一樣的存儲引擎實現覆蓋索引的方式都不一樣，並非全部存儲引擎都支持覆蓋索引(Memory和Falcon就不支持)。 對於索引覆蓋查詢(index-covered query)，使用EXPLAIN時，能夠在Extra一列中看到「Using index」。例如，在sakila的inventory表中，有一個組合索引(store_id,film_id)，對於只須要訪問這兩列的查詢，MySQL就可使用索引，以下： mysql> EXPLAIN SELECT store_id, film_id FROM sakila.inventory\G *************************** 1. row ***************************            id: 1 select_type: SIMPLE         table: inventory          type: index possible_keys: NULL           key: idx_store_id_film_id       key_len: 3           ref: NULL          rows: 5007         Extra: Using index 1 row in set (0.17 sec) 在大多數引擎中，只有當查詢語句所訪問的列是索引的一部分時，索引纔會覆蓋。可是，InnoDB不限於此，InnoDB的二級索引在葉子節點中存儲了primary key的值。所以，sakila.actor表使用InnoDB，並且對因而last_name上有索引，因此，索引能覆蓋那些訪問actor_id的查詢，如： mysql> EXPLAIN SELECT actor_id, last_name     -> FROM sakila.actor WHERE last_name = 'HOPPER'\G *************************** 1. row ***************************            id: 1 select_type: SIMPLE         table: actor          type: ref possible_keys: idx_actor_last_name           key: idx_actor_last_name       key_len: 137           ref: const          rows: 2         Extra: Using where; Using index 3.三、利用索引進行排序 MySQL中，有兩種方式生成有序結果集：一是使用filesort，二是按索引順序掃描。利用索引進行排序操做是很是快的，並且能夠利用同一索引同時進行查找和排序操做。當索引的順序與ORDER BY中的列順序相同且全部的列是同一方向(所有升序或者所有降序)時，可使用索引來排序。若是查詢是鏈接多個表，僅當ORDER BY中的全部列都是第一個表的列時纔會使用索引。其它狀況都會使用filesort。 create table actor( actor_id int unsigned NOT NULL AUTO_INCREMENT, name      varchar(16) NOT NULL DEFAULT '', password        varchar(16) NOT NULL DEFAULT '', PRIMARY KEY(actor_id), KEY     (name) ) ENGINE=InnoDB insert into actor(name,password) values('cat01','1234567'); insert into actor(name,password) values('cat02','1234567'); insert into actor(name,password) values('ddddd','1234567'); insert into actor(name,password) values('aaaaa','1234567'); mysql> explain select actor_id from actor order by actor_id \G *************************** 1. row ***************************            id: 1 select_type: SIMPLE         table: actor          type: index possible_keys: NULL           key: PRIMARY       key_len: 4           ref: NULL          rows: 4         Extra: Using index 1 row in set (0.00 sec) mysql> explain select actor_id from actor order by password \G *************************** 1. row ***************************            id: 1 select_type: SIMPLE         table: actor          type: ALL possible_keys: NULL           key: NULL       key_len: NULL           ref: NULL          rows: 4         Extra: Using filesort 1 row in set (0.00 sec) mysql> explain select actor_id from actor order by name \G *************************** 1. row ***************************            id: 1 select_type: SIMPLE         table: actor          type: index possible_keys: NULL           key: name       key_len: 18           ref: NULL          rows: 4         Extra: Using index 1 row in set (0.00 sec) 當MySQL不能使用索引進行排序時，就會利用本身的排序算法(快速排序算法)在內存(sort buffer)中對數據進行排序，若是內存裝載不下，它會將磁盤上的數據進行分塊，再對各個數據塊進行排序，而後將各個塊合併成有序的結果集（實際上就是外排序）。對於filesort，MySQL有兩種排序算法。 (1)兩遍掃描算法(Two passes) 實現方式是先將需要排序的字段和能夠直接定位到相關行數據的指針信息取出，而後在設定的內存（經過參數sort_buffer_size設定）中進行排序，完成排序以後再次經過行指針信息取出所需的Columns。 注：該算法是4.1以前採用的算法，它須要兩次訪問數據，尤爲是第二次讀取操做會致使大量的隨機I/O操做。另外一方面，內存開銷較小。 (3)    一次掃描算法(single pass) 該算法一次性將所需的Columns所有取出，在內存中排序後直接將結果輸出。 注：從 MySQL 4.1 版本開始使用該算法。它減小了I/O的次數，效率較高，可是內存開銷也較大。若是咱們將並不須要的Columns也取出來，就會極大地浪費排序過程所須要的內存。在 MySQL 4.1 以後的版本中，能夠經過設置 max_length_for_sort_data 參數來控制 MySQL 選擇第一種排序算法仍是第二種。當取出的全部大字段總大小大於 max_length_for_sort_data 的設置時，MySQL 就會選擇使用第一種排序算法，反之，則會選擇第二種。爲了儘量地提升排序性能，咱們天然更但願使用第二種排序算法，因此在 Query 中僅僅取出須要的 Columns 是很是有必要的。 當對鏈接操做進行排序時，若是ORDER BY僅僅引用第一個表的列，MySQL對該表進行filesort操做，而後進行鏈接處理，此時，EXPLAIN輸出「Using filesort」；不然，MySQL必須將查詢的結果集生成一個臨時表，在鏈接完成以後進行filesort操做，此時，EXPLAIN輸出「Using temporary;Using filesort」。 3.四、索引與加鎖 索引對於InnoDB很是重要，由於它可讓查詢鎖更少的元組。這點十分重要，由於MySQL 5.0中，InnoDB直到事務提交時纔會解鎖。有兩個方面的緣由：首先，即便InnoDB行級鎖的開銷很是高效，內存開銷也較小，但無論怎麼樣，仍是存在開銷。其次，對不須要的元組的加鎖，會增長鎖的開銷，下降併發性。 InnoDB僅對須要訪問的元組加鎖，而索引可以減小InnoDB訪問的元組數。可是，只有在存儲引擎層過濾掉那些不須要的數據才能達到這種目的。一旦索引不容許InnoDB那樣作（即達不到過濾的目的），MySQL服務器只能對InnoDB返回的數據進行WHERE操做，此時，已經沒法避免對那些元組加鎖了：InnoDB已經鎖住那些元組，服務器沒法解鎖了。 來看個例子： create table actor( actor_id int unsigned NOT NULL AUTO_INCREMENT, name      varchar(16) NOT NULL DEFAULT '', password        varchar(16) NOT NULL DEFAULT '', PRIMARY KEY(actor_id), KEY     (name) ) ENGINE=InnoDB insert into actor(name,password) values('cat01','1234567'); insert into actor(name,password) values('cat02','1234567'); insert into actor(name,password) values('ddddd','1234567'); insert into actor(name,password) values('aaaaa','1234567'); SET AUTOCOMMIT=0; BEGIN; SELECT actor_id FROM actor WHERE actor_id < 4 AND actor_id <> 1 FOR UPDATE; 該查詢僅僅返回2---3的數據，實際已經對1---3的數據加上排它鎖了。InnoDB鎖住元組1是由於MySQL的查詢計劃僅使用索引進行範圍查詢（而沒有進行過濾操做，WHERE中第二個條件已經沒法使用索引了）： mysql> EXPLAIN SELECT actor_id FROM test.actor     -> WHERE actor_id < 4 AND actor_id <> 1 FOR UPDATE \G *************************** 1. row ***************************            id: 1 select_type: SIMPLE         table: actor          type: index possible_keys: PRIMARY           key: PRIMARY       key_len: 4           ref: NULL          rows: 4         Extra: Using where; Using index 1 row in set (0.00 sec) mysql> 代表存儲引擎從索引的起始處開始，獲取全部的行，直到actor_id<4爲假，服務器沒法告訴InnoDB去掉元組1。 爲了證實row 1已經被鎖住，咱們另外建一個鏈接，執行以下操做： SET AUTOCOMMIT=0; BEGIN; SELECT actor_id FROM actor WHERE actor_id = 1 FOR UPDATE; 該查詢會被掛起，直到第一個鏈接的事務提交釋放鎖時，纔會執行（這種行爲對於基於語句的複製(statement-based replication)是必要的）。 如上所示，當使用索引時，InnoDB會鎖住它不須要的元組。更糟糕的是，若是查詢不能使用索引，MySQL會進行全表掃描，並鎖住每個元組，無論是否真正須要。