MySQL 最佳化的簡單原則

在最佳化查詢中，資料庫應用（如MySQL）即意味著對工具的操作與使用。使用索引、使用EXPLAIN分析查詢以及調整MySQL的內部配置可達到最佳化查詢的目的。

任何一位元據庫程式員都會有這樣的體會：高通訊量的資料庫驅動程式中，一條糟糕的SQL查詢語句可對整個應用程式的運行產生嚴重的影響，其不僅消耗掉更多的資料庫時間，且它將對其他應用組件產生影響。

如同其它學科，最佳化查詢效能很大程度上決定於開發人員的直覺。幸運的是，像MySQL這樣的資料庫內建有一些協助工具。本文簡要討論諸多工具之三種：使用索引，使用EXPLAIN分析查詢以及調整MySQL的內部配置。

#1: 使用索引

MySQL允許對資料庫表進行索引，以此能迅速尋找記錄，而無需一開始就掃描整個表，由此顯著地加快查詢速度。每個表最多可以做到16個索引，此外MySQL還支援多列索引及全文檢索索引。

給表添加一個索引非常簡單，只需調用一個CREATE INDEX命令並為索引指定它的域即可。列表A給出了一個例子：

列表 A

mysql> CREATE INDEX idx_username ON users(username);
Query OK, 1 row affected (0.15 sec)
Records: 1  Duplicates: 0  Warnings: 0

這裡，對users表的username域做索引，以確保在WHERE或者HAVING子句中引用這一域的SELECT查詢語句運行速度比沒有添加索引時要快。通過SHOW INDEX命令可以查看索引已被建立（列表B）。

列表 B

mysql> SHOW INDEX FROM users;
--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name     | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| users |          1 | idx_username |            1 | username    | A         |      NULL |     NULL | NULL   | YES  | BTREE      |         |
--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
1 row in set (0.00 sec)

值得注意的是：索引就像一把雙刃劍。對錶的每一域做索引通常沒有必要，且很可能導致運行速度減慢，因為向表中插入或修改資料時，MySQL不得不每次都為這些額外的工作重建立立索引。另一方面，避免對錶的每一域做索引同樣不是一個非常好的主意，因為在提高插入記錄的速度時，導致查詢操作的速度減慢。這就需要找到一個平衡點，比如在設計索引系統時，考慮表的主要功能（資料修複及編輯）不失為一種明智的選擇。

#2: 最佳化查詢效能

在分析查詢效能時，考慮EXPLAIN關鍵字同樣很管用。EXPLAIN關鍵字一般放在SELECT查詢語句的前面，用於描述MySQL如何執行查詢操作、以及MySQL成功返回結果集需要執行的行數。下面的一個簡單例子可以說明（列表C）這一過程：

列表 C

mysql> EXPLAIN SELECT city.name, city.district FROM city, country WHERE city.countrycode = country.code AND country.code = 'IND';
+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------------+
| id | select_type | table   | type  | possible_keys | key     | key_len | ref  | rows | Extra       |
+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------------+
|  1 | SIMPLE      | country | const | PRIMARY       | PRIMARY | 3       | const |    1 | Using index |
|  1 | SIMPLE      | city    | ALL   | NULL          | NULL    | NULL    | NULL | 4079 | Using where |
+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------------+
2 rows in set (0.00 sec)這裡查詢是基於兩個表串連。EXPLAIN關鍵字描述了MySQL是如何處理串連這兩個表。必須清楚的是，當前設計要求MySQL處理的是country表中的一條記錄以及city表中的整個4019條記錄。這就意味著，還可使用其他的最佳化技巧改進其查詢方法。例如，給city表添加如下索引（列表D）：

列表 D

mysql> CREATE INDEX idx_ccode ON city(countrycode);
Query OK, 4079 rows affected (0.15 sec)
Records: 4079  Duplicates: 0  Warnings: 0

現在，當我們重新使用EXPLAIN關鍵字進行查詢時，我們可以看到一個顯著的改進（列表E）：

列表 E

mysql> EXPLAIN SELECT city.name, city.district FROM city, country WHERE city.countrycode = country.code AND country.code = 'IND';
+----+-------------+---------+-------+---------------+-----------+---------+-------+------+-------------+
| id | select_type | table   | type  | possible_keys | key       | key_len | ref   | rows | Extra       |
+----+-------------+---------+-------+---------------+-----------+---------+-------+------+-------------+
|  1 | SIMPLE      | country | const | PRIMARY       | PRIMARY   | 3       | const |    1 | Using index |
|  1 | SIMPLE      | city    | ref   | idx_ccode     | idx_ccode | 3       | const |  333 | Using where |
+----+-------------+---------+-------+---------------+-----------+---------+-------+------+-------------+
2 rows in set (0.01 sec)

在這個例子中，MySQL現在只需要掃描city表中的333條記錄就可產生一個結果集，其掃描記錄數幾乎減少了90％！自然，資料庫資源的查詢速度更快，效率更高。

#3: 調整內部變數

MySQL是如此的開放，所以可輕鬆地進一步調整其預設設定以獲得更優的效能及穩定性。需要最佳化的一些關鍵變數如下：

• 改變索引緩衝長度(key_buffer)

一般，該變數控制緩衝區的長度在處理索引表（讀/寫操作）時使用。MySQL使用手冊指出該變數可以不斷增加以確保索引表的最佳效能，並推薦使用與系統記憶體25％的大小作為該變數的值。這是MySQL十分重要的組態變數之一，如果你對最佳化和提高系統效能有興趣，可以從改變key_buffer_size變數的值開始。

• 改變表長(read_buffer_size)

當一個查詢不斷地掃描某一個表，MySQL會為它分配一段記憶體緩衝區。read_buffer_size變數控制這一緩衝區的大小。如果你認為連續掃描進行得太慢，可以通過增加該變數值以及記憶體緩衝區大小提高其效能。

• 設定開啟表的數目的最大值(table_cache)

該變數控制MySQL在任何時候開啟表的最大數目，由此能控制伺服器響應輸入請求的能力。它跟max_connections變數密切相關，增加table_cache值可使MySQL開啟更多的表，就如增加max_connections值可增加串連數一樣。當收到大量不同資料庫及表的請求時，可以考慮改變這一值的大小。

• 對緩長查詢設定一個時間限制(long_query_time)

MySQL帶有“慢查詢日誌”，它會自動地記錄所有的在一個特定的時間範圍內尚未結束的查詢。這個日誌對於跟蹤那些低效率或者行為不端的查詢以及尋找最佳化對象都非常有用。long_query_time變數控制這一最大時間限定，以秒為單位。

以上討論並給出用於分析和最佳化SQL查詢的三種工具的使用方法，以此提高你的應用程式效能。使用它們快樂地最佳化吧！

 

 

explain顯示了mysql如何使用索引來處理select語句以及串連表。可以協助選擇更好的索引和寫出更最佳化的查詢語句。使用方法，在select語句前加上explain就可以了：如：explain select surname,first_name form a,b where a.id=b.id分析結果形式如下：tabletypepossible_keyskeykey_lenrefrowsExtraarangeidfirst_nameFirst_name9NULL23112Using whereUsing temporaryUsing filesort brefidfirst_nameid4id2Using where EXPLAIN列的解釋：table顯示這一行的資料是關於哪張表的type 這是重要的列，顯示串連使用了何種類型。從最好到最差的連線類型為const、eq_reg、ref、range、indexhe和ALLpossible_keys顯示可能應用在這張表中的索引。如果為空白，沒有可能的索引。可以為相關的域從WHERE語句中選擇一個合適的語句key 實際使用的索引。如果為NULL，則沒有使用索引。很少的情況下，MYSQL會選擇最佳化不足的索引。這種情況下，可以在SELECT語句中使用USE INDEX（indexname）來強制使用一個索引或者用IGNORE INDEX（indexname）來強制MYSQL忽略索引key_len 使用的索引的長度。在不損失精確性的情況下，長度越短越好ref 顯示索引的哪一列被使用了，如果可能的話，是一個常數rows MYSQL認為必須檢查的用來返回請求資料的行數Extra  關於MYSQL如何解析查詢的額外資訊。將在表4.3中討論，但這裡可以看到的壞的例子是Using temporary和Using filesort，意思MYSQL根本不能使用索引，結果是檢索會很慢 extra列返回的描述的意義Distinct一旦MYSQL找到了與行相聯合匹配的行，就不再搜尋了Not exists MYSQL最佳化了LEFT JOIN，一旦它找到了匹配LEFT JOIN標準的行，就不再搜尋了Range checked for eachRecord（index map:#） 沒有找到理想的索引，因此對於從前面表中來的每一個行組合，MYSQL檢查使用哪個索引，並用它來從表中返回行。這是使用索引的最慢的串連之一Using filesort 看到這個的時候，查詢就需要最佳化了。MYSQL需要進行額外的步驟來發現如何對返回的行排序。它根據連線類型以及儲存排序索引值和匹配條件的全部行的行指標來排序全部行Using index 列資料是從僅僅使用了索引中的資訊而沒有讀取實際的行動的表返回的，這發生在對錶的全部的請求列都是同一個索引的部分的時候Using temporary 看到這個的時候，查詢需要最佳化了。這裡，MYSQL需要建立一個暫存資料表來儲存結果，這通常發生在對不同的列集進行ORDER BY上，而不是GROUP BY上Where used 使用了WHERE從句來限制哪些行將與下一張表匹配或者是返回給使用者。如果不想返回表中的全部行，並且連線類型ALL或index，這就會發生，或者是查詢有問題 不同連線類型的解釋（按照效率高低的順序排序）system表只有一行：system表。這是const連線類型的特殊情況const 表中的一個記錄的最大值能夠匹配這個查詢（索引可以是主鍵或惟一索引）。因為只有一行，這個值實際就是常數，因為MYSQL先讀這個值然後把它當做常數來對待eq_ref 在串連中，MYSQL在查詢時，從前面的表中，對每一個記錄的聯合都從表中讀取一個記錄，它在查詢使用了索引為主鍵或惟一鍵的全部時使用ref 這個連線類型只有在查詢使用了不是惟一或主鍵的鍵或者是這些類型的部分（比如，利用最左邊首碼）時發生。對於之前的表的每一個行聯合，全部記錄都將從表中讀出。這個類型嚴重依賴於根據索引匹配的記錄多少—越少越好range 這個連線類型使用索引返回一個範圍中的行，比如使用>或<尋找東西時發生的情況index 這個連線類型對前面的表中的每一個記錄聯合進行完全掃描（比ALL更好，因為索引一般小於表資料）ALL 這個連線類型對於前面的每一個記錄聯合進行完全掃描，這一般比較糟糕，應該盡量避免