MySQL性能優化的最佳12條經驗

數據庫的操做愈來愈成爲整個應用的性能瓶頸了，這點對於Web應用尤爲明顯。關於數據庫的性能，這並不僅是DBA才須要擔憂的事，而這更是我 們程序員須要去關注的事情。當咱們去設計數據庫表結構，對操做數據庫時（尤爲是查表時的SQL語句），

咱們都須要注意數據操做的性能。這裏，咱們不會講過 多的SQL語句的優化，而只是針對MySQL這一Web應用最多的數據庫。但願下面的這些優化技巧對你有用。

1. 爲查詢緩存優化你的查詢

大多數的MySQL服務器都開啓了查詢緩存。這是提升性最有效的方法之一，並且這是被MySQL的數據庫引擎處理的。當有不少相同的查詢被執行了屢次的時候，這些查詢結果會被放到一個緩存中，這樣，後續的相同的查詢就不用操做表而直接訪問緩存結果了。

這裏最主要的問題是，對於程序員來講，這個事情是很容易被忽略的。由於，咱們某些查詢語句會讓MySQL不使用緩存。請看下面的示例：

1 // 查詢緩存不開啓
2 $r = mysql_query("SELECT username FROM user WHERE signup_date >= CURDATE()");
3 
4 // 開啓查詢緩存
5 $today = date("Y-m-d");
6 $r = mysql_query("SELECT username FROM user WHERE signup_date >= '$today'");

上面兩條SQL語句的差異就是 CURDATE() ，MySQL的查詢緩存對這個函數不起做用。因此，像 NOW() 和 RAND() 或是其它的諸如此類的SQL函數都不會開啓查詢緩存，由於這些函數的返回是會不定的易變的。

因此，你所須要的就是用一個變量來代替MySQL的函數，從而 開啓緩存。

2. EXPLAIN 你的 SELECT 查詢

使用 EXPLAIN 關鍵字可讓你知道MySQL是如何處理你的SQL語句的。這能夠幫你分析你的查詢語句或是表結構的性能瓶頸。

EXPLAIN 的查詢結果還會告訴你你的索引主鍵被如何利用的，你的數據表是如何被搜索和排序的……等等，等等。

挑一個你的SELECT語句（推薦挑選那個最複雜的，有多表聯接的），把關鍵字EXPLAIN加到前面。你可使用phpmyadmin來作這個事。而後，你會看到一張表格。

3. 當只要一行數據時使用 LIMIT 1

當你查詢表的有些時候，你已經知道結果只會有一條結果，但由於你可能須要去fetch遊標，或是你也許會去檢查返回的記錄數。

在這種狀況下，加上 LIMIT 1 能夠增長性能。這樣同樣，MySQL數據庫引擎會在找到一條數據後中止搜索，而不是繼續日後查少下一條符合記錄的數據。

下面的示例，只是爲了找一下是否有「中國」的用戶，很明顯，後面的會比前面的更有效率。（請注意，第一條中是Select *，第二條是Select 1）

1 // 沒有效率的：
 2 $r = mysql_query("SELECT * FROM user WHERE country = 'China'");
 3 if (mysql_num_rows($r) > 0) {
 4     // ...
 5 }
 6 
 7 // 有效率的：
 8 $r = mysql_query("SELECT 1 FROM user WHERE country = 'China' LIMIT 1");
 9 if (mysql_num_rows($r) > 0) {
10     // ...
11 }

4. 爲搜索字段建索引

索引並不必定就是給主鍵或是惟一的字段。若是在你的表中，有某個字段你總要會常常用來作搜索，那麼，請爲其創建索引吧。

另外，你應該也須要知道什麼樣的搜索是不能使用正常的索引的。例如，當你須要在一篇大的文章中搜索一個詞時，

如： 「WHERE post_content LIKE ‘%apple%’」，索引多是沒有意義的。你可能須要使用MySQL全文索引 或是本身作一個索引（好比說：搜索關鍵詞或是Tag什麼的）

5. 在Join表的時候使用至關類型的例，並將其索引

若是你的應用程序有不少 JOIN 查詢，你應該確認兩個表中Join的字段是被建過索引的。這樣，MySQL內部會啓動爲你優化Join的SQL語句的機制。

並且，這些被用來Join的字段，應該是相同的類型的。例如：若是你要把 DECIMAL 字段和一個 INT 字段Join在一塊兒，MySQL就沒法使用它們的索引。對於那些STRING類型，還須要有相同的字符集才行。（兩個表的字符集有可能不同）

1 // 在state中查找company
2 $r = mysql_query("SELECT company_name FROM users
3     LEFT JOIN companies ON (users.state = companies.state)
4     WHERE users.id = $user_id");
5 
6 // 兩個 state 字段應該是被建過索引的，並且應該是至關的類型，相同的字符集。

6. 千萬不要 ORDER BY RAND()

想打亂返回的數據行？隨機挑一個數據？真不知道誰發明了這種用法，但不少新手很喜歡這樣用。但你確不瞭解這樣作有多麼可怕的性能問題。

若是你真的想把返回的數據行打亂了，你有N種方法能夠達到這個目的。這樣使用只讓你的數據庫的性能呈指數級的降低。

這裏的問題是：MySQL會不得 不去執行RAND()函數（很耗CPU時間），並且這是爲了每一行記錄去記行，而後再對其排序。就算是你用了Limit 1也無濟於事（由於要排序）
下面的示例是隨機挑一條記錄

1 // 千萬不要這樣作：
2 $r = mysql_query("SELECT username FROM user ORDER BY RAND() LIMIT 1");
3 
4 // 這要會更好：
5 $r = mysql_query("SELECT count(*) FROM user");
6 $d = mysql_fetch_row($r);
7 $rand = mt_rand(0,$d[0] - 1);
8 
9 $r = mysql_query("SELECT username FROM user LIMIT $rand, 1");

7. 避免 SELECT *

從數據庫裏讀出越多的數據，那麼查詢就會變得越慢。而且，若是你的數據庫服務器和WEB服務器是兩臺獨立的服務器的話，這還會增長網絡傳輸的負載。因此，你應該養成一個須要什麼就取什麼的好的習慣。

// 不推薦
$r = mysql_query("SELECT * FROM user WHERE user_id = 1");
$d = mysql_fetch_assoc($r);
echo "Welcome {$d['username']}";

// 推薦
$r = mysql_query("SELECT username FROM user WHERE user_id = 1");
$d = mysql_fetch_assoc($r);
echo "Welcome {$d['username']}";

8. 永遠爲每張表設置一個ID

咱們應該爲數據庫裏的每張表都設置一個ID作爲其主鍵，並且最好的是一個INT型的（推薦使用UNSIGNED），並設置上自動增長的AUTO_INCREMENT標誌。

就算是你 users 表有一個主鍵叫 「email」的字段，你也別讓它成爲主鍵。使用 VARCHAR 類型來當主鍵會使用得性能降低。另外，在你的程序中，你應該使用表的ID來構造你的數據結構。

並且，在MySQL數據引擎下，還有一些操做須要使用主鍵，在這些狀況下，主鍵的性能和設置變得很是重要，好比，集羣，分區……

在這裏，只有一個狀況是例外，那就是「關聯表」的「外鍵」，也就是說，這個表的主鍵，經過若干個別的表的主鍵構成。咱們把這個狀況叫作「外鍵」。

好比：有一個「學生表」有學生的ID，有一個「課程表」有課程ID，那麼，「成績表」就是「關聯表」了，其關聯了學生表和課程表，在成績表中，學生ID和課程ID叫「外鍵」其共同組成主鍵。

9. 使用 ENUM 而不是 VARCHAR

ENUM 類型是很是快和緊湊的。在實際上，其保存的是 TINYINT，但其外表上顯示爲字符串。這樣一來，用這個字段來作一些選項列表變得至關的完美。

若是你有一個字段，好比「性別」，「國家」，「民族」，「狀態」或「部門」，你知道這些字段的取值是有限並且固定的，那麼，你應該使用 ENUM 而不是 VARCHAR。

MySQL也有一個「建議」（見第十條）告訴你怎麼去從新組織你的表結構。當你有一個 VARCHAR 字段時，這個建議會告訴你把其改爲 ENUM 類型。使用 PROCEDURE ANALYSE() 你能夠獲得相關的建議。

10. 從 PROCEDURE ANALYSE() 取得建議

PROCEDURE ANALYSE() 會讓 MySQL 幫你去分析你的字段和其實際的數據，並會給你一些有用的建議。只有表中有實際的數據，這些建議纔會變得有用，由於要作一些大的決定是須要有數據做爲基礎的。

例如，若是你建立了一個 INT 字段做爲你的主鍵，然而並無太多的數據，那麼，PROCEDURE ANALYSE()會建議你把這個字段的類型改爲MEDIUMINT 。

或是你使用了一個 VARCHAR 字段，由於數據很少，你可能會獲得一個讓你把它改爲 ENUM 的建議。這些建議，都是可能由於數據不夠多，因此決策作得就不夠準。

必定要注意，這些只是建議，只有當你的表裏的數據愈來愈多時，這些建議纔會變得準確。必定要記住，你纔是最終作決定的人。

11. 儘量的使用 NOT NULL

除非你有一個很特別的緣由去使用 NULL 值，你應該老是讓你的字段保持 NOT NULL。這看起來好像有點爭議，請往下看。

首先，問問你本身「Empty」和「NULL」有多大的區別（若是是INT，那就是0和NULL）？若是你以爲它們之間沒有什麼區別，那麼你就不要使用NULL。（你知道嗎？在 Oracle 裏，NULL 和 Empty 的字符串是同樣的！)

不要覺得 NULL 不須要空間，其須要額外的空間，而且，在你進行比較的時候，你的程序會更復雜。 固然，這裏並非說你就不能使用NULL了，現實狀況是很複雜的，依然會有些狀況下，你須要使用NULL值。

下面摘自MySQL本身的文檔：

「NULL columns require additional space in the row to record whether their values are NULL. For MyISAM tables, each NULL column takes one bit extra, rounded up to the nearest byte.」

12. Prepared Statements

Prepared Statements很像存儲過程，是一種運行在後臺的SQL語句集合，咱們能夠從使用 prepared statements 得到不少好處，不管是性能問題仍是安全問題。

Prepared Statements 能夠檢查一些你綁定好的變量，這樣能夠保護你的程序不會受到「SQL注入式」攻擊。固然，你也能夠手動地檢查你的這些變量，然而，手動的檢查容易出問題，並且很常常會被程序員忘了。

當咱們使用一些framework或是ORM的時候，這樣的問題會好一些。

在性能方面，當一個相同的查詢被使用屢次的時候，這會爲你帶來可觀的性能優點。你能夠給這些Prepared Statements定義一些參數，而MySQL只會解析一次。

雖然最新版本的MySQL在傳輸Prepared Statements是使用二進制形勢，因此這會使得網絡傳輸很是有效率。

固然，也有一些狀況下，咱們須要避免使用Prepared Statements，由於其不支持查詢緩存。但聽說版本5.1後支持了。

在PHP中要使用prepared statements，你能夠查看其使用手冊：mysqli 擴展 或是使用數據庫抽象層，如： PDO.

1 // 建立 prepared statement
 2 if ($stmt = $mysqli->prepare("SELECT username FROM user WHERE state=?")) {
 3 
 4     // 綁定參數
 5     $stmt->bind_param("s", $state);
 6 
 7     // 執行
 8     $stmt->execute();
 9 
10     // 綁定結果
11     $stmt->bind_result($username);
12 
13     // 移動遊標
14     $stmt->fetch();
15 
16     printf("%s is from %s\n", $username, $state);
17 
18     $stmt->close();
19 }