mysql效能最佳化

標籤：

1.查詢快取最佳化你的查詢

 

show variables like "%query_cache%"  //查看是否開啟緩衝

開啟命令：

set global query_cache_type = 1;  
set global query_cache_size = 600000;

 

2.EXPLAIN 你的 SELECT 查詢

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

EXPLAIN select count(*) from `dw_account_log` where user_id=17;  //user_id未使用索引

 

EXPLAIN select count(*) from `dw_account_log` where user_id=17;  //user_id使用索引

 

 

 

 

3.為搜尋欄位建索引

1.添加PRIMARY KEY（主鍵索引）
mysql>ALTER TABLE `table_name` ADD PRIMARY KEY (`column`)
2.添加UNIQUE(唯一索引)
mysql>ALTER TABLE `table_name` ADD UNIQUE (`column`)
3.添加INDEX(普通索引)
mysql>ALTER TABLE `table_name` ADD INDEX index_name ( `column` )
4.添加FULLTEXT(全文索引)
mysql>ALTER TABLE `table_name` ADD FULLTEXT ( `column`)
5.添加多列索引
mysql>ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` )

 

 

則最簡單的語句應該是：select * from `dw_account_log` where type like ‘%name%‘; 這樣。但是這樣存在的這樣一個缺陷，就是資料庫要進行全表掃描，不能使用索引，如果資料量大了的話，搜尋效率非常低下。可使用全文索引  select * from `dw_account_log` where MATCH(`type`) AGAINST(‘realname‘ IN BOOLEAN MODE);  但不支援中文  可使用中文編碼儲存 （不確定） 4.  在Join表的時候使用相當類型的例，並將其索引

如果你的應用程式有很多 JOIN 查詢，你應該確認兩個表中Join的欄位是被建過索引的。這樣，MySQL內部會啟動為你最佳化Join的SQL語句的機制。

而且，這些被用來Join的欄位，應該是相同的類型的。例如：如果你要把 DECIMAL 欄位和一個 INT 欄位Join在一起，MySQL就無法使用它們的索引。對於那些STRING類型，還需要有相同的字元集才行。（兩個表的字元集有可能不一樣）  // 在state中尋找company
$r = mysql_query("SELECT company_name FROM users  LEFT JOIN companies ON (users.state = companies.state)  WHERE users.id = $user_id");  
// 兩個 state 欄位應該是被建過索引的，而且應該是相當的類型，相同的字元集。   6. 千萬不要 ORDER BY RAND()

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

如果你真的想把返回的資料行打亂了，你有N種方法可以達到這個目的。這樣使用只讓你的資料庫的效能呈指數級的下降。這裡的問題是：MySQL會不得不去執行RAND()函數（很耗CPU時間），而且這是為了每一行記錄去記行，然後再對其排序。就算是你用了Limit 1也無濟於事（因為要排序）  // 千萬不要這樣做：
$r = mysql_query("SELECT username FROM user ORDER BY RAND() LIMIT 1");

// 這要會更好：
$r = mysql_query("SELECT count(*) FROM user");
$d = mysql_fetch_row($r);
$rand = mt_rand(0,$d[0] - 1);

$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來構造你的資料結構。 

 

9. 使用 ENUM 而不是 VARCHAR

ENUM 類型是非常快和緊湊的。在實際上，其儲存的是 TINYINT，但其外表上顯示為字串。這樣一來，用這個欄位來做一些選項列表變得相當的完美。

如果你有一個欄位，比如“性別”，“國家”，“民族”，“狀態”或“部門”，你知道這些欄位的取值是有限而且固定的，那麼，你應該使用 ENUM 而不是 VARCHAR。

MySQL也有一個“建議”（見第十條）告訴你怎麼去重新組織你的表結構。當你有一個 VARCHAR 欄位時，這個建議會告訴你把其改成 ENUM 類型。使用 PROCEDURE ANALYSE() 你可以得到相關的建議。 

 

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.” 

 

13. 無緩衝的查詢

正常的情況下，當你在當你在你的指令碼中執行一個SQL語句的時候，你的程式會停在那裡直到沒這個SQL語句返回，然後你的程式再往下繼續執行。你可以使用無緩衝查詢來改變這個行為。

關於這個事情，在PHP的文檔中有一個非常不錯的說明： mysql_unbuffered_query() 函數：

“mysql_unbuffered_query() sends the SQL query query to MySQL without automatically fetching and buffering the result rows as mysql_query() does. This saves a considerable amount of memory with SQL queries that produce large result sets, and you can start working on the result set immediately after the first row has been retrieved as you don‘t have to wait until the complete SQL query has been performed.”

上面那句話翻譯過來是說，mysql_unbuffered_query() 發送一個SQL語句到MySQL而並不像mysql_query()一樣去自動fethch和緩衝結果。這會相當節約很多可觀的記憶體，尤其是那些會產生大量結果的查詢語句，並且，你不需要等到所有的結果都返回，只需要第一行資料返回的時候，你就可以開始馬上開始工作於查詢結果了。

然而，這會有一些限制。因為你要麼把所有行都讀走，或是你要在進行下一次的查詢前調用 mysql_free_result() 清除結果。而且， mysql_num_rows() 或 mysql_data_seek() 將無法使用。所以，是否使用無緩衝的查詢你需要仔細考慮。 

 

14. 把IP地址存成 UNSIGNED INT

很多程式員都會建立一個 VARCHAR(15) 欄位來存放字串形式的IP而不是整形的IP。如果你用整形來存放，只需要4個位元組，並且你可以有定長的欄位。而且，這會為你帶來查詢上的優勢，尤其是當你需要使用這樣的WHERE條件：IP between ip1 and ip2。

我們必需要使用UNSIGNED INT，因為 IP地址會使用整個32位的無符號整形。

而你的查詢，你可以使用 INET_ATON() 來把一個字串IP轉成一個整形，並使用 INET_NTOA() 把一個整形轉成一個字串IP。在PHP中，也有這樣的函數 ip2long() 和 long2ip()。
1 $r = "UPDATE users SET ip = INET_ATON(‘{$_SERVER[‘REMOTE_ADDR‘]}‘) WHERE user_id = $user_id"; 

 

15. 固定長度的表會更快

如果表中的所有欄位都是“固定長度”的，整個表會被認為是 “static” 或 “fixed-length”。 例如，表中沒有如下類型的欄位： VARCHAR，TEXT，BLOB。只要你包括了其中一個這些欄位，那麼這個表就不是“固定長度靜態表”了，這樣，MySQL 引擎會用另一種方法來處理。

固定長度的表會提高效能，因為MySQL搜尋得會更快一些，因為這些固定的長度是很容易計算下一個資料的位移量的，所以讀取的自然也會很快。而如果欄位不是定長的，那麼，每一次要找下一條的話，需要程式找到主鍵。

並且，固定長度的表也更容易被緩衝和重建。不過，唯一的副作用是，固定長度的欄位會浪費一些空間，因為定長的欄位無論你用不用，他都是要分配那麼多的空間。

使用“垂直分割”技術（見下一條），你可以分割你的表成為兩個一個是定長的，一個則是不定長的。

 

16. 垂直分割

“垂直分割”是一種把資料庫中的表按列變成幾張表的方法，這樣可以降低表的複雜度和欄位的數目，從而達到最佳化的目的。（以前，在銀行做過項目，見過一張表有100多個欄位，很恐怖）

樣本一：在Users表中有一個欄位是家庭地址，這個欄位是可選欄位，相比起，而且你在資料庫操作的時候除了個人資訊外，你並不需要經常讀取或是改寫這個欄位。那麼，為什麼不把他放到另外一張表中呢？ 這樣會讓你的表有更好的效能，大家想想是不是，大量的時候，我對於使用者表來說，只有使用者ID，使用者名稱，口令，使用者角色等會被經常使用。小一點的表總是會有好的效能。

樣本二： 你有一個叫 “last_login” 的欄位，它會在每次使用者登入時被更新。但是，每次更新時會導致該表的查詢快取被清空。所以，你可以把這個欄位放到另一個表中，這樣就不會影響你對使用者識別碼，使用者名稱，使用者角色的不停地讀取了，因為查詢快取會幫你增加很多效能。

另外，你需要注意的是，這些被分出去的欄位所形成的表，你不會經常性地去Join他們，不然的話，這樣的效能會比不分割時還要差，而且，會是極數級的下降。 

 

17. 拆分大的 DELETE 或 INSERT 語句

如果你需要在一個線上的網站上去執行一個大的 DELETE 或 INSERT 查詢，你需要非常小心，要避免你的操作讓你的整個網站停止相應。因為這兩個操作是會鎖表的，表一鎖住了，別的操作都進不來了。

Apache 會有很多的子進程或線程。所以，其工作起來相當有效率，而我們的伺服器也不希望有太多的子進程，線程和資料庫連結，這是極大的占伺服器資源的事情，尤其是記憶體。

如果你把你的表鎖上一段時間，比如30秒鐘，那麼對於一個有很高訪問量的網站來說，這30秒所積累的訪問進程/線程，資料庫連結，開啟的檔案數，可能不僅僅會讓你泊WEB服務Crash，還可能會讓你的整台伺服器馬上掛了。

所以，如果你有一個大的處理，你定你一定把其拆分，使用 LIMIT 條件是一個好的方法。下面是一個樣本：

 
while (1) {
//每次只做1000條
mysql_query("DELETE FROM logs WHERE log_date <= ‘2009-11-01‘ LIMIT 1000");
if (mysql_affected_rows() == 0) {
// 沒得可刪了，退出！
break;
}
// 每次都要休息一會兒
usleep(50000);
}   19. 選擇正確的儲存引擎

在 MySQL 中有兩個儲存引擎 MyISAM 和 InnoDB，每個引擎都有利有弊。酷殼以前文章《MySQL: InnoDB 還是 MyISAM?》討論和這個事情。

MyISAM 適合於一些需要大量查詢的應用，但其對於有大量寫操作並不是很好。甚至你只是需要update一個欄位，整個表都會被鎖起來，而別的進程，就算是讀進程都無法操作直到讀操作完成。另外，MyISAM 對於 SELECT COUNT(*) 這類的計算是超快無比的。

InnoDB 的趨勢會是一個非常複雜的儲存引擎，對於一些小的應用，它會比 MyISAM 還慢。他是它支援“行鎖” ，於是在寫操作比較多的時候，會更優秀。並且，他還支援更多的進階應用程式，比如：事務。     20. 使用一個對象關係映射器（Object Relational Mapper）

使用 ORM (Object Relational Mapper)，你能夠獲得可靠的效能增漲。一個ORM可以做的所有事情，也能被手動的編寫出來。但是，這需要一個進階專家。

ORM 的最重要的是“Lazy Loading”，也就是說，只有在需要的去取值的時候才會去真正的去做。但你也需要小心這種機制的副作用，因為這很有可能會因為要去建立很多很多小的查詢反而會降低效能。

ORM 還可以把你的SQL語句打包成一個事務，這會比單獨執行他們快得多得多。

目前，個人最喜歡的PHP的ORM是：Doctrine。    21. 小心“永久連結”

“永久連結”的目的是用來減少重新建立MySQL連結的次數。當一個連結被建立了，它會永遠處在串連的狀態，就算是資料庫操作已經結束了。而且，自從我們的Apache開始重用它的子進程後——也就是說，下一次的HTTP請求會重用Apache的子進程，並重用相同的 MySQL 連結。

* PHP手冊：mysql_pconnect()

在理論上來說，這聽起來非常的不錯。但是從個人經驗（也是大多數人的）上來說，這個功能製造出來的麻煩事更多。因為，你只有有限的連結數，記憶體問題，檔案控制代碼數，等等。

而且，Apache 運行在極端並行的環境中，會建立很多很多的了進程。這就是為什麼這種“永久連結”的機制工作地不好的原因。在你決定要使用“永久連結”之前，你需要好好地考慮一下你的整個系統的架構。

 

 

   

 

mysql效能最佳化