mysql索引的使用和優化

參考：

http://blog.csdn.net/xluren/article/details/32746183

http://www.cnblogs.com/hustcat/archive/2009/10/28/1591648.html

 

關於MySQL索引的好處，若是正確合理設計而且使用索引的MySQL是一輛蘭博基尼的話，那麼沒有設計和使用索引的MySQL就是一我的力三輪車。對於沒有索引的表，單表查詢可能幾十萬數據就是瓶頸，而一般大型網站單日就可能會產生幾十萬甚至幾百萬的數據，沒有索引查詢會變的很是緩慢。仍是以WordPress來講，其多個數據表都會對常常被查詢的字段添加索引，好比wp_comments表中針對5個字段設計了BTREE索引。

一個簡單的對比測試

以我去年測試的數據做爲一個簡單示例，20多條數據源隨機生成200萬條數據，平均每條數據源都重複大概10萬次，表結構比較簡單，僅包含一個自增ID，一個char類型，一個text類型和一個int類型，單表2G大小，使用MyIASM引擎。開始測試未添加任何索引。

執行下面的SQL語句：

1	mysql> SELECT id,FROM_UNIXTIME(time) FROM article WHERE a.title='測試標題'

查詢須要的時間很是恐怖的，若是加上聯合查詢和其餘一些約束條件，數據庫會瘋狂的消耗內存，而且會影響前端程序的執行。這時給title字段添加一個BTREE索引：

1	mysql> ALTER TABLE article ADD INDEX index_article_title ON title(200);

再次執行上述查詢語句，其對比很是明顯：

 

MySQL索引的概念

索引是一種特殊的文件(InnoDB數據表上的索引是表空間的一個組成部分)，它們包含着對數據表裏全部記錄的引用指針。更通俗的說，數據庫索引比如是一本書前面的目錄，能加快數據庫的查詢速度。上述SQL語句，在沒有索引的狀況下，數據庫會遍歷所有200條數據後選擇符合條件的；而有了相應的索引以後，數據庫會直接在索引中查找符合條件的選項。若是咱們把SQL語句換成「SELECT * FROM article WHERE id=2000000」，那麼你是但願數據庫按照順序讀取完200萬行數據之後給你結果仍是直接在索引中定位呢？上面的兩個圖片鮮明的用時對比已經給出了答案（注：通常數據庫默認都會爲主鍵生成索引）。

索引分爲聚簇索引和非聚簇索引兩種，聚簇索引是按照數據存放的物理位置爲順序的，而非聚簇索引就不同了；聚簇索引能提升多行檢索的速度，而非聚簇索引對於單行的檢索很快。

MySQL索引的類型

1. 普通索引

這是最基本的索引，它沒有任何限制，好比上文中爲title字段建立的索引就是一個普通索引，MyIASM中默認的BTREE類型的索引，也是咱們大多數狀況下用到的索引。

01

–直接建立索引

02	CREATE INDEX index_name ON table(column(length))

03	–修改表結構的方式添加索引

04	ALTER TABLE table_name ADD INDEX index_name ON (column(length))

05	–建立表的時候同時建立索引

06	CREATE TABLE `table` (

07	`id` int(11) NOT NULL AUTO_INCREMENT ,

08	`title` char(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,

09	`content` text CHARACTER SET utf8 COLLATE utf8_general_ci NULL ,

10	`time` int(10) NULL DEFAULT NULL ,

11	PRIMARY KEY (`id`),

12	INDEX index_name (title(length))

13

)

14

–刪除索引

15	DROP INDEX index_name ON table

2. 惟一索引

與普通索引相似，不一樣的就是：索引列的值必須惟一，但容許有空值（注意和主鍵不一樣）。若是是組合索引，則列值的組合必須惟一，建立方法和普通索引相似。

01

–建立惟一索引

02	CREATE UNIQUE INDEX indexName ON table(column(length))

03

–修改表結構

04	ALTER TABLE table_name ADD UNIQUE indexName ON (column(length))

05	–建立表的時候直接指定

06	CREATE TABLE `table` (

07	`id` int(11) NOT NULL AUTO_INCREMENT ,

08	`title` char(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,

09	`content` text CHARACTER SET utf8 COLLATE utf8_general_ci NULL ,

10	`time` int(10) NULL DEFAULT NULL ,

11	PRIMARY KEY (`id`),

12	UNIQUE indexName (title(length))

13

);

3. 全文索引（FULLTEXT）

MySQL從3.23.23版開始支持全文索引和全文檢索，FULLTEXT索引僅可用於 MyISAM 表；他們能夠從CHAR、VARCHAR或TEXT列中做爲CREATE TABLE語句的一部分被建立，或是隨後使用ALTER TABLE 或CREATE INDEX被添加。////對於較大的數據集，將你的資料輸入一個沒有FULLTEXT索引的表中，而後建立索引，其速度比把資料輸入現有FULLTEXT索引的速度更爲快。不過切記對於大容量的數據表，生成全文索引是一個很是消耗時間很是消耗硬盤空間的作法。

01	–建立表的適合添加全文索引

02	CREATE TABLE `table` (

03	`id` int(11) NOT NULL AUTO_INCREMENT ,

04	`title` char(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,

05	`content` text CHARACTER SET utf8 COLLATE utf8_general_ci NULL ,

06	`time` int(10) NULL DEFAULT NULL ,

07	PRIMARY KEY (`id`),

08	FULLTEXT (content)

09

);

10	–修改表結構添加全文索引

11	ALTER TABLE article ADD FULLTEXT index_content(content)

12

–直接建立索引

13	CREATE FULLTEXT INDEX index_content ON article(content)

4. 單列索引、多列索引

多個單列索引與單個多列索引的查詢效果不一樣，由於執行查詢時，MySQL只能使用一個索引，會從多個索引中選擇一個限制最爲嚴格的索引。

5. 組合索引（最左前綴）

平時用的SQL查詢語句通常都有比較多的限制條件，因此爲了進一步榨取MySQL的效率，就要考慮創建組合索引。例如上表中針對title和time創建一個組合索引：ALTER TABLE article ADD INDEX index_titme_time (title(50),time(10))。創建這樣的組合索引，實際上是至關於分別創建了下面兩組組合索引：

–title,time

–title

爲何沒有time這樣的組合索引呢？這是由於MySQL組合索引「最左前綴」的結果。簡單的理解就是隻從最左面的開始組合。並非只要包含這兩列的查詢都會用到該組合索引，以下面的幾個SQL所示：

1

–使用到上面的索引

2	SELECT * FROM article WHREE title='測試' AND time=1234567890;

3	SELECT * FROM article WHREE utitle='測試';

4

–不使用上面的索引

5	SELECT * FROM article WHREE time=1234567890;

MySQL索引的優化

上面都在說使用索引的好處，但過多的使用索引將會形成濫用。所以索引也會有它的缺點：雖然索引大大提升了查詢速度，同時卻會下降更新表的速度，如對錶進行INSERT、UPDATE和DELETE。由於更新表時，MySQL不只要保存數據，還要保存一下索引文件。創建索引會佔用磁盤空間的索引文件。通常狀況這個問題不太嚴重，但若是你在一個大表上建立了多種組合索引，索引文件的會膨脹很快。索引只是提升效率的一個因素，若是你的MySQL有大數據量的表，就須要花時間研究創建最優秀的索引，或優化查詢語句。下面是一些總結以及收藏的MySQL索引的注意事項和優化方法。

1. 什麼時候使用匯集索引或非彙集索引？

動做描述	使用匯集索引	使用非彙集索引
列常常被分組排序	使用	使用
返回某範圍內的數據	使用	不使用
一個或極少不一樣值	不使用	不使用
小數目的不一樣值	使用	不使用
大數目的不一樣值	不使用	使用
頻繁更新的列	不使用	使用
外鍵列	使用	使用
主鍵列	使用	使用
頻繁修改索引列	不使用	使用

事實上，咱們能夠經過前面彙集索引和非彙集索引的定義的例子來理解上表。如：返回某範圍內的數據一項。好比您的某個表有一個時間列，剛好您把聚合索引創建在了該列，這時您查詢2004年1月1日至2004年10月1日之間的所有數據時，這個速度就將是很快的，由於您的這本字典正文是按日期進行排序的，聚類索引只須要找到要檢索的全部數據中的開頭和結尾數據便可；而不像非彙集索引，必須先查到目錄中查到每一項數據對應的頁碼，而後再根據頁碼查到具體內容。其實這個具體用法我還不是很理解，只能等待後期的項目開發中慢慢學學了。

2. 索引不會包含有NULL值的列

只要列中包含有NULL值都將不會被包含在索引中，複合索引中只要有一列含有NULL值，那麼這一列對於此複合索引就是無效的。因此咱們在數據庫設計時不要讓字段的默認值爲NULL。

3. 使用短索引

對串列進行索引，若是可能應該指定一個前綴長度。例如，若是有一個CHAR(255)的列，若是在前10個或20個字符內，多數值是唯一的，那麼就不要對整個列進行索引。短索引不只能夠提升查詢速度並且能夠節省磁盤空間和I/O操做。

4. 索引列排序

MySQL查詢只使用一個索引，所以若是where子句中已經使用了索引的話，那麼order by中的列是不會使用索引的。所以數據庫默認排序能夠符合要求的狀況下不要使用排序操做；儘可能不要包含多個列的排序，若是須要最好給這些列建立複合索引。

5. like語句操做

通常狀況下不鼓勵使用like操做，若是非使用不可，如何使用也是一個問題。like 「%aaa%」 不會使用索引而like 「aaa%」可使用索引。

6. 不要在列上進行運算

例如：select * from users where YEAR(adddate)<2007，將在每一個行上進行運算，這將致使索引失效而進行全表掃描，所以咱們能夠改爲：select * from users where adddate<’2007-01-01′。關於這一點能夠圍觀：一個單引號引起的MYSQL性能損失。

最後總結一下，MySQL只對一下操做符才使用索引：<,<=,=,>,>=,between,in,以及某些時候的like(不以通配符%或_開頭的情形)。而理論上每張表裏面最多可建立16個索引，不過除非是數據量真的不少，不然過多的使用索引也不是那麼好玩的，好比我剛纔針對text類型的字段建立索引的時候，系統差點就卡死了。

 

索引與優化

寫在前面：索引對查詢的速度有着相當重要的影響，理解索引也是進行數據庫性能調優的起點。考慮以下狀況，假設數據庫中一個表有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會進行全表掃描，並鎖住每個元組，無論是否真正須要。