MySQL優化索引

1.  MySQL如何使用索引

索引用於快速查找具備特定列值的行。若是沒有索引，MySQL必須從第一行開始，而後遍歷整個表以找到相關的行。表越大，花費越多。若是表中有相關列的索引，MySQL能夠快速肯定要在數據文件中間查找的位置，而沒必要查看全部數據。這比順序讀取每一行要快得多。

大多數MySQL索引（PRIMARY KEY，UNIQUE，INDEX和FULLTEXT）存儲在B樹（B-tree）中。例外狀況：空間數據類型的索引使用R樹； MEMORY表還支持哈希索引。 InnoDB對FULLTEXT索引使用倒排列表。

MySQL使用索引進行如下操做：

• 快速查找與WHERE子句匹配的行
• 若是能夠在多個索引之間進行選擇，則MySQL一般會使用查找最小行數（最具選擇性的索引）的索引
• 有多列索引（也叫「複合索引」或者「聯合索引」），那麼優化器可使用索引的任何最左前綴來查找行。 例如，若是在（col1，col2，col3）上有一個三列索引，則在（col1），（col1，col2）和（col1，col2，col3）上都有索引搜索功能。
• 使用關聯（join）查詢從其餘表中檢索行時，若是聲明相同的類型和大小，MySQL能夠更有效地在列上使用索引。在這種狀況下，若是將VARCHAR和CHAR聲明爲相同的大小，則認爲它們相同。例如，VARCHAR（10）和CHAR（10）的大小相同，但VARCHAR（10）和CHAR（15）的大小不一樣。
• 對於非二進制字符串列之間的比較，兩個列應使用相同的字符集
• 若是排序或分組是在可用索引的最左前綴（例如，ORDER BY key_part1，key_part2）上完成的，則對錶進行排序或分組。若是在全部key部分後面都跟隨有DESC，則將以相反的順序讀取key。
• 在某些狀況下，MySQL可使用索引來知足ORDER BY子句，並避免執行文件排序操做時涉及的額外排序。
• 在某些狀況下，能夠優化查詢以檢索值而無需查詢數據行。（爲查詢提供全部必要結果的索引稱爲覆蓋索引）若是查詢僅從表中使用某些索引中包含的列，則能夠從索引樹中檢索所選值以提升速度

 最後，索引對小表的查詢不過重要。當查詢須要訪問大多數行時，順序讀取比處理索引快。

2.  避免全表掃描

當MySQL使用全表掃描來解析查詢時，EXPLAIN的輸出在type列中顯示ALL。 這一般在如下狀況下發生：

• 表過小，以致於執行全表掃描要比索引查找要快得多。對於少於10行且行長度較短的表，這是很常見的。
• 在ON或WHERE字句中沒有使用索引列。
• 將索引列與常量值進行比較，而MySQL已計算（基於索引樹）常量覆蓋了表的很大一部分而且表掃描會更快。
• 你正在經過另外一列使用基數低的鍵（許多行與鍵值匹配）。在這種狀況下，MySQL假定經過使用該鍵，它有可能執行許多鍵查找，而且表掃描會更快。 

對於小表，表掃描一般是合適的，而且對性能的影響能夠忽略不計。 

對於大表，能夠嘗試如下技術，以免優化器錯誤地選擇表掃描：

• 用ANALYZE TABLE tbl_name來更新key的分佈
• 使用FORCE INDEX來告訴MySQL相比於使用給定的索引來講，表掃描是很是昂貴的

3.  列索引

B樹（B-tree）數據結構使索引能夠在WHERE子句中快速找到與運算符（例如=，>，≤，BETWEEN，IN等）相對應的特定值，一組值或一系列值。 

每一個存儲引擎都會定義每一個表的最大索引數和最大索引長度。全部存儲引擎支持每一個表至少16個索引，而且索引總長度至少爲256個字節。

索引前綴

用col_name(N)能夠建立僅使用列的前N個字符的索引。在InnoDB表中，前綴最長767字節。

全文索引

FULLTEXT索引用於全文搜索。僅InnoDB和MyISAM存儲引擎支持FULLTEXT索引，而且僅支持CHAR，VARCHAR和TEXT列。索引始終在整個列上進行，而且不支持列前綴索引。

空間索引

指依據空間對象的位置和形狀或空間對象之間的某種空間關係按必定的順序排列的一種數據結構

MEMORY存儲引擎上的索引

默認狀況下，MEMORY存儲引擎使用HASH索引，但也支持BTREE索引。 

4.  多列索引

MySQL能夠建立複合索引（即多列上的索引）。 一個索引最多能夠包含16列。

假設有一張表示這樣定義的： 

CREATE TABLE test (
    id         INT NOT NULL,
    last_name  CHAR(30) NOT NULL,
    first_name CHAR(30) NOT NULL,
    PRIMARY KEY (id),
    INDEX idx_name (last_name,first_name)
);

idx_name索引是創建在last_name和first_name列之上的索引，該索引能夠用於指定了last_name和first_name值組合的查詢，也能夠用於僅指定last_name值的查詢，由於該索引是最左前綴匹配的。

所以，idx_name索引能夠用於下列查詢：

SELECT * FROM test WHERE last_name='Jones';

SELECT * FROM test WHERE last_name='Jones' AND first_name='John';

SELECT * FROM test WHERE last_name='Jones' AND (first_name='John' OR first_name='Jon');

SELECT * FROM test WHERE last_name='Jones' AND first_name >='M' AND first_name < 'N';

然而，idx_name索引不能用於下列查詢：

SELECT * FROM test WHERE first_name='John';

SELECT * FROM test WHERE last_name='Jones' OR first_name='John';

考慮下面的SQL：

SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2;

若是在col1和col2上存在一個多列索引，那麼能夠直接抓取適當的行。若是col1和col2上分別存在單獨的單列索引，則優化器將嘗試使用索引合併優化，或者經過肯定哪一個索引須要排除更多行來查找限制性最強的索引，並使用該索引來獲取行。

若是表具備多列索引，那麼優化器可使用該索引的任何最左前綴來查找行。例如，若是有一個三列索引(col1, col2, col3)，那麼在(col1), (col1, col2), (col1, col2, col3) 上具備索引搜索功能。

若是列不構成索引的最左前綴，則MySQL沒法使用索引執行查找。

再看下面的SQL語句：

SELECT * FROM tbl_name WHERE col1=val1;
SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2;

SELECT * FROM tbl_name WHERE col2=val2;
SELECT * FROM tbl_name WHERE col2=val2 AND col3=val3;

若是在（col1, col2, col3）上存在複合索引，那麼只有前兩個查詢會使用。然後最後兩個查詢不會使用索引來執行查找，由於（col2）和（col2，col3）並非（col1，col2，col3）的最左前綴。

5.  B-Tree 和 Hash 索引的比較

B樹索引特徵 

B樹（B-tree）索引可用於使用=，>，>=，<，<=，BETWEEN運算符的表達式中的列比較。若是LIKE的參數是一個不以通配符開頭的常量字符串，則該索引也能夠用於LIKE比較。

下列這些子句不會使用索引：

/* the LIKE value begins with a wildcard character */
SELECT * FROM tbl_name WHERE key_col LIKE '%Patrick%';
/*  the LIKE value is not a constant */
SELECT * FROM tbl_name WHERE key_col LIKE other_col;

沒有覆蓋WHERE子句中全部AND級別的任何索引都不會用於優化查詢。換句話說，爲了可以使用索引，必須在每一個AND組中使用索引的前綴。

下列WHERE子句會使用索引：

... WHERE index_part1=1 AND index_part2=2 AND other_column=3

    /* index = 1 OR index = 2 */
... WHERE index=1 OR A=10 AND index=2

    /* optimized like "index_part1='hello'" */
... WHERE index_part1='hello' AND index_part3=5

    /* Can use index on index1 but not on index2 or index3 */
... WHERE index1=1 AND index2=2 OR index1=3 AND index3=3;

下面這些WHERE子句不會使用索引：

   /* index_part1 is not used */
... WHERE index_part2=1 AND index_part3=2

    /*  Index is not used in both parts of the WHERE clause  */
... WHERE index=1 OR A=10

    /* No index spans all rows  */
... WHERE index_part1=1 OR index_part2=10

有時，即便有可用的索引，MySQL也不使用索引。發生這種狀況的一種可能緣由是，優化器估計使用索引將須要訪問表中很大比例的行。（在這種狀況下，表掃描可能會更快，由於它須要更少的查找。）可是，若是這樣的查詢使用LIMIT只檢索某些行，則MySQL仍然使用索引，由於它能夠更快地找到返回結果的幾行。

哈希索引特徵

哈希索引與剛剛討論的索引具備一些不一樣的特徵：

• 哈希索引只用於=或者<=>運算符的相等比較（但很是快），不用於比較運算符來查找值的範圍。依賴於這種單值查找的系統被稱爲「鍵值對存儲」，爲了將MySQL用於此類應用，請儘量地使用哈希索引。
• 優化器沒法使用哈希索引來加快 ORDER BY 操做。（哈希類型的索引不能用於按順序搜索下一個條目）
• MySQL沒法肯定兩個值之間大約有多少行（範圍優化器使用它來決定使用哪一個索引）
• 只有整個keys可用於搜索行。（對於B樹索引，key的任何最左邊的前綴均可用於查找行）

B-tree

樹型數據結構，普遍用於數據庫索引中。該結構始終保持有序，從而能夠快速查找精確匹配（等於運算符）和範圍（例如，大於，小於和BETWEEN運算符）。 此類索引可用於大多數存儲引擎，例如InnoDB和MyISAM。

由於B樹節點能夠有不少子節點，因此B樹與二叉樹不一樣，後者的每一個節點最多隻能有2個子節點。

術語B樹的使用旨在參考索引設計的通常類別。因爲經典B樹設計中不存在複雜性，MySQL存儲引擎使用的B樹結構可能被視爲變體。

Hash index

一種索引類型，專用於使用相等運算符而不是範圍運算符的查詢。 它可用於MEMORY表。 儘管出於歷史緣由，哈希索引是MEMORY表的默認索引，可是該存儲引擎還支持B樹索引，對於通常用途的查詢而言，B樹索引一般是更好的選擇。

6.  優化數據大小

設計表以使得它們在磁盤上佔用最少的空間。 經過減小寫入磁盤和從磁盤讀取的數據量，這能夠帶來巨大的改進。 較小的表一般在查詢執行期間處理其內容時須要較少的主內存。表數據的任何空間減小都會致使索引變小，從而能夠更快地處理索引。

MySQL支持許多不一樣的存儲引擎（表類型）和行格式。對於每一個表，能夠決定使用哪一種存儲和索引方法。爲應用程序選擇適當的表格式能夠大大提升性能。 

Table Columns

• 儘量使用最有效（最小）的數據類型。MySQL具備許多專門的類型，能夠節省磁盤空間和內存。例如，若是可能，使用較小的整數類型以得到較小的表。MEDIUMINT一般比INT更好，由於MEDIUMINT列使用的空間要少25％。
• 若是可能，將列聲明爲NOT NULL。經過更好地使用索引並消除測試每一個值是否爲NULL的開銷，它可使SQL操做更快。並且還節省了一些存儲空間，每列一比特。若是表中確實須要NULL值，那就用它們。只要避免使用默認設置，該默認設置容許每列中都爲NULL值。

Row Format 

• 爲了經過壓縮形式存儲表數據來進一步減小空間，請在建立InnoDB表時指定ROW_FORMAT=COMPRESSED

Indexes 

• 表的主鍵索引應儘量短。這使得識別每一行變得容易而高效。對於InnoDB表，主鍵列在每一個輔助索引條目中都是重複的，所以若是你有許多輔助索引，則較短的主鍵可節省大量空間。
• 僅建立須要提升查詢性能的索引。索引很適合檢索，可是會下降插入和更新操做的速度。若是你主要經過搜索列的組合來訪問表，請在表上建立單個組合索引，而不是爲每一個列建立單獨的索引。索引的第一部分應該是最經常使用的列。若是從表中查詢時老是使用許多列，則索引中的第一列應是重複次數最多的列，以便更好地壓縮索引。
• 若是是一個長字符串列，則極可能在第一個字符上具備惟一的前綴，這種狀況下最好使用MySQL前綴進行索引（PS：只對前幾個字符進行索引）。索引越短越快，這不只是由於它們須要較少的磁盤空間，並且還由於它們還會使索引緩存中的命中次數增長，從而減小磁盤尋道次數。 

Joins

• 在具備相同數據類型的不一樣表中聲明具備相同信息的列，以加快基於相應列的聯接。
• 保持列名簡單，以即可以在不一樣的表中使用相同的名稱，並簡化聯接查詢。例如，在名爲customer的表中，使用name列名代替customer_name。爲了使你的名稱可移植到其餘SQL服務器中，請考慮將名稱長度控制在18個字符之內。 

Normalization

• 一般，儘可能保持全部數據不冗餘(數據庫理論中稱爲第三範式)。爲它們分配惟一的id來代替一個重複冗長的值，根據須要在多個較小的表中重複這些id，並經過在join子句中引用id來鏈接查詢中的表。 

7.  優化數據類型

數值類型

• 行的惟一標識最好使用數值而不是字符串，由於大數值比相應的字符串佔用更少的存儲字節，所以傳輸和比較它們更快，佔用的內存也更少。

字符和字符串類型

• 在比較來自不一樣列的值時，儘量使用相同的字符集和排序規則聲明這些列，以免在運行查詢時進行字符串轉換。
• 對於小於8KB的列值，請使用二進制VARCHAR而不是BLOB。 GROUP BY和ORDER BY子句能夠生成臨時表，而且若是原始表不包含任何BLOB列，則這些臨時表可使用MEMORY存儲引擎。
• 若是一個表包含名稱和地址等字符串列，可是許多查詢沒有檢索這些列，那麼能夠考慮將字符串列分割成單獨的表，並在必要時使用帶有外鍵的鏈接查詢。當MySQL從一行中檢索任何值時，它讀取包含該行全部列(可能還有其餘相鄰行)的數據塊。保持每行較小，只包含最經常使用的列，可讓每一個數據塊容納更多的行。這種緊湊的表減小了常見查詢的磁盤I/O和內存使用。
• 當在InnoDB表中使用一個隨機生成的值做爲主鍵時，最好在它前面加上一個升序值，好比當前日期和時間(若是可能的話)。當連續的主鍵值物理上彼此相鄰存儲時，InnoDB能夠更快地插入和檢索它們。

其它

• ORDER BY 和 GROUP BY 使用的列不一致，或者 在鏈接查詢中ORDER BY 或 GROUP BY 使用了第一個表之外的表的列時會使用臨時表
• MySQL對每一個表有4096列的硬限制，可是對於給定的表，有效最大值可能會更少。 InnoDB對每一個表有1017列的限制。

 

https://dev.mysql.com/doc/refman/5.7/en/optimization.html