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
分析結果形式如下:
table
type
possible_keys
key
key_len
ref
rows
Extra
a
range
id
first_name
First_name
9
NULL
23112
Using where
Using temporary
Using filesort
 b
ref
id
first_name
id
4
id
2
Using where
 
EXPLAIN列的解釋:
table
顯示這一行的數據是關於哪張表的
type
 
這是重要的列,顯示連接使用了何種類型。從最好到最差的連接類型爲const、eq_reg、ref、range、indexhe和ALL
possible_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 each
Record(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
 
這個連接類型對於前面的每一個記錄聯合進行完全掃描,這一般比較糟糕,應該儘量避免
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章