以下就是跟大家分享的19個(gè)MySQL性能優(yōu)化主要要點(diǎn)，一起學(xué)習(xí)學(xué)習(xí)。

1、為查詢優(yōu)化你的查詢
大多數(shù)的MySQL服務(wù)器都開啟了查詢緩存。這是提高性最有效的方法之一，而且這是被MySQL的數(shù)據(jù)庫引擎處理的。當(dāng)有很多相同的查詢被執(zhí)行了多次的時(shí)候，這些查詢結(jié)果會(huì)被放到一個(gè)緩存中，這樣，后續(xù)的相同的查詢就不用操作表而直接訪問緩存結(jié)果了。

這里最主要的問題是，對(duì)于程序員來說，這個(gè)事情是很容易被忽略的。因?yàn)?，我們某些查詢語句會(huì)讓MySQL不使用緩存。請(qǐng)看下面的示例：

// 查詢緩存不開啟 $r = mysql_query("SELECT username FROM user WHERE  signup_date >= CURDATE()"); // 開啟查詢緩存 $today = date("Y-m-d"); $r = mysql_query("SELECT username FROM user WHERE signup_date >= '$today'");

上面兩條SQL語句的差別就是 CURDATE() ，MySQL的查詢緩存對(duì)這個(gè)函數(shù)不起作用。所以，像 NOW() 和 RAND() 或是其它的諸如此類的SQL函數(shù)都不會(huì)開啟查詢緩存，因?yàn)檫@些函數(shù)的返回是會(huì)不定的易變的。所以，你所需要的就是用一個(gè)變量來代替MySQL的函數(shù)，從而開啟緩存。

2、EXPLAIN 你的SELECT查詢
使用EXPLAIN關(guān)鍵字可以讓你知道MySQL是如何處理你的SQL語句的。

有表關(guān)聯(lián)的查詢，如下列：

select username, group_name from users u joins groups g on (u.group_id = g.id)

發(fā)現(xiàn)查詢緩慢，然后在group_id字段上增加索引，則會(huì)加快查詢

3、當(dāng)只要一行數(shù)據(jù)時(shí)使用LIMIT 1
當(dāng)你查詢表的有些時(shí)候，你已經(jīng)知道結(jié)果只會(huì)有一條結(jié)果，單因?yàn)槟憧赡苄枰etch游標(biāo)，或是你也許會(huì)去檢查返回的記錄數(shù)。

在這種情況下，加上LIMIT 1 可以增加性能。這樣一樣， MySQL數(shù)據(jù)庫引擎會(huì)在找到一條數(shù)據(jù)后停止搜索，而不是繼續(xù)往后查找下一條符合記錄的數(shù)據(jù)。

下面的示例，只是為了找一下是否有“中國”的用戶，很明顯，后面的會(huì)比前面的更有效率。（請(qǐng)注意，第一條中是Select *，第二條是Select 1）

// 沒有效率的： $r = mysql_query("SELECT * FROM user WHERE country = 'China'"); if (mysql_num_rows($r) > 0) {  // ... } // 有效率的： $r = mysql_query("SELECT 1 FROM user WHERE country = 'China' LIMIT 1"); if (mysql_num_rows($r) > 0) { // ... }

4、為搜索字段建索引
索引并不一定就是給主鍵或是唯一的字段。如果在你的表中，有某個(gè)字段你總要會(huì)經(jīng)常用來做搜索，那么，請(qǐng)為其建立索引吧。

5、在Join表的時(shí)候使用相當(dāng)類型的列，并將其索引
如果你的應(yīng)用程序有很多JOIN查詢，你應(yīng)該確認(rèn)兩個(gè)表中Join的字段是被建過索引的。這樣，MySQL內(nèi)部會(huì)啟動(dòng)為你優(yōu)化Join的SQL語句的機(jī)制。

而且，這些被用來Join的字段，應(yīng)該是相同的類型的。例如：如果你要把DECIMAL字段和一個(gè)INT字段JOIN在一起，MYSQL就無法使用他們的索引。對(duì)于那些STRING類型，還需要有相同的字符集才行（兩個(gè)表的字符集有可能不一樣）

6、千萬不要ORDER BY RAND()

7、避免SELECT *
從數(shù)據(jù)庫里讀出越多的數(shù)據(jù)，那么查詢就會(huì)變得越慢。并且，如果你的數(shù)據(jù)庫服務(wù)器和WEB服務(wù)器是兩臺(tái)獨(dú)立的服務(wù)器的話，這還會(huì)增加網(wǎng)絡(luò)傳輸?shù)呢?fù)載。

所以，你應(yīng)該養(yǎng)成一個(gè)需要什么就取什么的好的習(xí)慣。

// 不推薦 $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、永遠(yuǎn)為兩張表設(shè)置一個(gè)ID
我們應(yīng)該為數(shù)據(jù)庫里的每張表都設(shè)置一個(gè)ID作為其主鍵，而最好的是一個(gè)INT型（推薦使用UNSIGNED），并設(shè)置上自動(dòng)增長(zhǎng)的AUTO INCREMENT標(biāo)志。

就算是你 users 表有一個(gè)主鍵叫 “email”的字段，你也別讓它成為主鍵。使用 VARCHAR 類型來當(dāng)主鍵會(huì)使用得性能下降。另外，在你的程序中，你應(yīng)該使用表的ID來構(gòu)造你的數(shù)據(jù)結(jié)構(gòu)。 而且，在MySQL數(shù)據(jù)引擎下，還有一些操作需要使用主鍵，在這些情況下，主鍵的性能和設(shè)置變得非常重要，比如，集群，分區(qū)……

9、使用 ENUM 而不是 VARCHAR ？
ENUM 類型是非?？旌途o湊的。在實(shí)際上，其保存的是 TINYINT，但其外表上顯示為字符串。這樣一來，用這個(gè)字段來做一些選項(xiàng)列表變得相當(dāng)?shù)耐昝馈?/p>

如果你有一個(gè)字段，比如“性別”，“國家”，“民族”，“狀態(tài)”或“部門”，你知道這些字段的取值是有限而且固定的，那么，你應(yīng)該使用 ENUM 而不是 VARCHAR。

10、從 PROCEDURE ANALYSE() 取得建議 ？
PROCEDURE ANALYSE() 會(huì)讓 MySQL 幫你去分析你的字段和其實(shí)際的數(shù)據(jù)，并會(huì)給你一些有用的建議。只有表中有實(shí)際的數(shù)據(jù)，這些建議才會(huì)變得有用，因?yàn)橐鲆恍┐蟮臎Q定是需要有數(shù)據(jù)作為基礎(chǔ)的。

例如，如果你創(chuàng)建了一個(gè) INT 字段作為你的主鍵，然而并沒有太多的數(shù)據(jù)，那么，PROCEDURE ANALYSE()會(huì)建議你把這個(gè)字段的類型改成 MEDIUMINT ?；蚴悄闶褂昧艘粋€(gè) VARCHAR 字段，因?yàn)閿?shù)據(jù)不多，你可能會(huì)得到一個(gè)讓你把它改成 ENUM 的建議。這些建議，都是可能因?yàn)閿?shù)據(jù)不夠多，所以決策做得就不夠準(zhǔn)。

11、盡可能的使用 NOT NULL
除非你有一個(gè)很特別的原因去使用 NULL 值，你應(yīng)該總是讓你的字段保持 NOT NULL。這看起來好像有點(diǎn)爭(zhēng)議，請(qǐng)往下看。

首先，問問你自己“Empty”和“NULL”有多大的區(qū)別（如果是INT，那就是0和NULL）？如果你覺得它們之間沒有什么區(qū)別，那么你就不要使用NULL。（你知道嗎？在 Oracle 里，NULL 和 Empty 的字符串是一樣的！)

不要以為 NULL 不需要空間，其需要額外的空間，并且，在你進(jìn)行比較的時(shí)候，你的程序會(huì)更復(fù)雜。 當(dāng)然，這里并不是說你就不能使用NULL了，現(xiàn)實(shí)情況是很復(fù)雜的，依然會(huì)有些情況下，你需要使用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、把IP地址存成 UNSIGNED INT
很多程序員都會(huì)創(chuàng)建一個(gè) VARCHAR(15) 字段來存放字符串形式的IP而不是整形的IP。如果你用整形來存放，只需要4個(gè)字節(jié)，并且你可以有定長(zhǎng)的字段。而且，這會(huì)為你帶來查詢上的優(yōu)勢(shì)，尤其是當(dāng)你需要使用這樣的WHERE條件：IP between ip1 and ip2。

我們必需要使用UNSIGNED INT，因?yàn)?IP地址會(huì)使用整個(gè)32位的無符號(hào)整形

13、固定長(zhǎng)度的表會(huì)更快
如果表中的所有字段都是“固定長(zhǎng)度”的，整個(gè)表會(huì)被認(rèn)為是 “static” 或 “fixed-length”。 例如，表中沒有如下類型的字段： VARCHAR，TEXT，BLOB。只要你包括了其中一個(gè)這些字段，那么這個(gè)表就不是“固定長(zhǎng)度靜態(tài)表”了，這樣，MySQL 引擎會(huì)用另一種方法來處理。

固定長(zhǎng)度的表會(huì)提高性能，因?yàn)镸ySQL搜尋得會(huì)更快一些，因?yàn)檫@些固定的長(zhǎng)度是很容易計(jì)算下一個(gè)數(shù)據(jù)的偏移量的，所以讀取的自然也會(huì)很快。而如果字段不是定長(zhǎng)的，那么，每一次要找下一條的話，需要程序找到主鍵。

并且，固定長(zhǎng)度的表也更容易被緩存和重建。不過，唯一的副作用是，固定長(zhǎng)度的字段會(huì)浪費(fèi)一些空間，因?yàn)槎ㄩL(zhǎng)的字段無論你用不用，他都是要分配那么多的空間。

14、垂直分割
“垂直分割”是一種把數(shù)據(jù)庫中的表按列變成幾張表的方法，這樣可以降低表的復(fù)雜度和字段的數(shù)目，從而達(dá)到優(yōu)化的目的。（以前，在銀行做過項(xiàng)目，見過一張表有100多個(gè)字段，很恐怖）

示例一：在Users表中有一個(gè)字段是家庭地址，這個(gè)字段是可選字段，相比起，而且你在數(shù)據(jù)庫操作的時(shí)候除了個(gè)人信息外，你并不需要經(jīng)常讀取或是改寫這個(gè)字段。那么，為什么不把他放到另外一張表中呢？ 這樣會(huì)讓你的表有更好的性能，大家想想是不是，大量的時(shí)候，我對(duì)于用戶表來說，只有用戶ID，用戶名，口令，用戶角色等會(huì)被經(jīng)常使用。小一點(diǎn)的表總是會(huì)有好的性能。

示例二： 你有一個(gè)叫 “l(fā)ast_login” 的字段，它會(huì)在每次用戶登錄時(shí)被更新。但是，每次更新時(shí)會(huì)導(dǎo)致該表的查詢緩存被清空。所以，你可以把這個(gè)字段放到另一個(gè)表中，這樣就不會(huì)影響你對(duì)用戶 ID，用戶名，用戶角色的不停地讀取了，因?yàn)椴樵兙彺鏁?huì)幫你增加很多性能。

另外，你需要注意的是，這些被分出去的字段所形成的表，你不會(huì)經(jīng)常性地去Join他們，不然的話，這樣的性能會(huì)比不分割時(shí)還要差，而且，會(huì)是極數(shù)級(jí)的下降。

15、拆分大的 DELETE 或 INSERT 語句
如果你需要在一個(gè)在線的網(wǎng)站上去執(zhí)行一個(gè)大的 DELETE 或 INSERT 查詢，你需要非常小心，要避免你的操作讓你的整個(gè)網(wǎng)站停止相應(yīng)。因?yàn)檫@兩個(gè)操作是會(huì)鎖表的，表一鎖住了，別的操作都進(jìn)不來了。

Apache 會(huì)有很多的子進(jìn)程或線程。所以，其工作起來相當(dāng)有效率，而我們的服務(wù)器也不希望有太多的子進(jìn)程，線程和數(shù)據(jù)庫鏈接，這是極大的占服務(wù)器資源的事情，尤其是內(nèi)存。

如果你把你的表鎖上一段時(shí)間，比如30秒鐘，那么對(duì)于一個(gè)有很高訪問量的站點(diǎn)來說，這30秒所積累的訪問進(jìn)程/線程，數(shù)據(jù)庫鏈接，打開的文件數(shù)，可能不僅僅會(huì)讓你泊WEB服務(wù)Crash，還可能會(huì)讓你的整臺(tái)服務(wù)器馬上掛了。

所以，如果你有一個(gè)大的處理，你定你一定把其拆分，使用 LIMIT 條件是一個(gè)好的方法。下面是一個(gè)示例：

while (1) { //每次只做1000條 mysql_query("DELETE FROM logs WHERE log_date <= '2009-11-01' LIMIT 1000"); if (mysql_affected_rows() == 0) {     // 沒得可刪了，退出！     break; } // 每次都要休息一會(huì)兒 usleep(50000); }

16、 越小的列會(huì)越快
對(duì)于大多數(shù)的數(shù)據(jù)庫引擎來說，硬盤操作可能是最重大的瓶頸。所以，把你的數(shù)據(jù)變得緊湊會(huì)對(duì)這種情況非常有幫助，因?yàn)檫@減少了對(duì)硬盤的訪問。

參看 MySQL 的文檔 Storage Requirements 查看所有的數(shù)據(jù)類型。

如果一個(gè)表只會(huì)有幾列罷了（比如說字典表，配置表），那么，我們就沒有理由使用 INT 來做主鍵，使用 MEDIUMINT, SMALLINT 或是更小的 TINYINT 會(huì)更經(jīng)濟(jì)一些。如果你不需要記錄時(shí)間，使用 DATE 要比 DATETIME 好得多。

當(dāng)然，你也需要留夠足夠的擴(kuò)展空間，不然，你日后來干這個(gè)事，你會(huì)死的很難看，參看Slashdot的例子（2009年11月06日），一個(gè)簡(jiǎn)單的ALTER TABLE語句花了3個(gè)多小時(shí)，因?yàn)槔锩嬗幸磺Я偃f條數(shù)據(jù)。

17、選擇一個(gè)正確的存儲(chǔ)引擎
在 MySQL 中有兩個(gè)存儲(chǔ)引擎 MyISAM 和 InnoDB，每個(gè)引擎都有利有弊?？釟ひ郧拔恼隆禡ySQL: InnoDB 還是 MyISAM?》討論和這個(gè)事情。

MyISAM 適合于一些需要大量查詢的應(yīng)用，但其對(duì)于有大量寫操作并不是很好。甚至你只是需要update一個(gè)字段，整個(gè)表都會(huì)被鎖起來，而別的進(jìn)程，就算是讀進(jìn)程都無法操作直到讀操作完成。另外，MyISAM 對(duì)于 SELECT COUNT(*) 這類的計(jì)算是超快無比的。

InnoDB 的趨勢(shì)會(huì)是一個(gè)非常復(fù)雜的存儲(chǔ)引擎，對(duì)于一些小的應(yīng)用，它會(huì)比 MyISAM 還慢。他是它支持“行鎖” ，于是在寫操作比較多的時(shí)候，會(huì)更優(yōu)秀。并且，他還支持更多的高級(jí)應(yīng)用，比如：事務(wù)。

18、小心“永久鏈接”
“永久鏈接”的目的是用來減少重新創(chuàng)建MySQL鏈接的次數(shù)。當(dāng)一個(gè)鏈接被創(chuàng)建了，它會(huì)永遠(yuǎn)處在連接的狀態(tài)，就算是數(shù)據(jù)庫操作已經(jīng)結(jié)束了。而且，自從我們的 Apache開始重用它的子進(jìn)程后——也就是說，下一次的HTTP請(qǐng)求會(huì)重用Apache的子進(jìn)程，并重用相同的 MySQL 鏈接。

PHP手冊(cè)：mysql_pconnect()

在理論上來說，這聽起來非常的不錯(cuò)。但是從個(gè)人經(jīng)驗(yàn)（也是大多數(shù)人的）上來說，這個(gè)功能制造出來的麻煩事更多。因?yàn)?，你只有有限的鏈接?shù)，內(nèi)存問題，文件句柄數(shù)，等等。

而且，Apache 運(yùn)行在極端并行的環(huán)境中，會(huì)創(chuàng)建很多很多的了進(jìn)程。這就是為什么這種“永久鏈接”的機(jī)制工作地不好的原因。在你決定要使用“永久鏈接”之前，你需要好好地考慮一下你的整個(gè)系統(tǒng)的架構(gòu)。

19、當(dāng)查詢較慢的時(shí)候，可用Join來改寫一下該查詢來進(jìn)行優(yōu)化

mysql> select sql_no_cache * from guang_deal_outs where deal_id in (select id from guang_deals where id = 100017151) ; Empty set (18.87 sec)  mysql> select sql_no_cache a.* from guang_deal_outs a inner join guang_deals b on a.deal_id = b.id where b.id = 100017151;  Empty set (0.01 sec)

原因

mysql> desc select sql_no_cache * from guang_deal_outs where deal_id in (select id from guang_deals where id = 100017151) ; +----+--------------------+-----------------+-------+---------------+---------+---------+-------+----------+-------------+ | id | select_type  | table   | type | possible_keys | key  | key_len | ref | rows  | Extra  | +----+--------------------+-----------------+-------+---------------+--------- +---------+-------+----------+-------------+ | 1 | PRIMARY   | guang_deal_outs | ALL | NULL   | NULL |  NULL | NULL | 18633779 | Using where | | 2 | DEPENDENT SUBQUERY | guang_deals  | const | PRIMARY  | PRIMARY |  4  | const |  1 | Using index | +----+--------------------+-----------------+-------+---------------+--------- +---------+-------+----------+-------------+ 2 rows in set (0.04 sec) mysql> desc select sql_no_cache a.* from guang_deal_outs a inner join guang_deals b on a.deal_id = b.id where b.id = 100017151; +----+-------------+-------+-------+---------------------- +----------------------+---------+-------+------+-------------+ | id | select_type | table | type | possible_keys  | key      | key_len | ref | rows | Extra  | +----+-------------+-------+-------+---------------------- +----------------------+---------+-------+------+-------------+ | 1 | SIMPLE  | b  | const | PRIMARY    | PRIMARY     | 4  | const | 1 | Using index | | 1 | SIMPLE  | a  | ref | idx_guang_dlout_dlid |  idx_guang_dlout_dlid | 4  | const | 1 |    | +----+-------------+-------+-------+---------------------- +----------------------+---------+-------+------+-------------+ 2 rows in set (0.05 sec)

其實(shí)在  guang_deal_outs 在deal_id 上也是有索引的。 其實(shí)我想把子查詢?cè)O(shè)置為

select * from guang_deal_outs where deal_id in (select id from guang_deals where id = 100017151);

變成下面的樣子

select * from guang_deal_outs where deal_id in (100017151);

但不幸的是，實(shí)際情況正好相反。MySQL試圖讓它和外面的表產(chǎn)生聯(lián)系來“幫助”優(yōu)化查詢，它認(rèn)為下面的exists形式更有效率

select * from guang_deal_outs where exists (select * from guang_deals where id = 100017151 and id = guang_deal_outs.deal_id);

這種in子查詢的形式，在外部表（比如上面的guang_deals）數(shù)據(jù)量比較大的時(shí)候效率是很差的（如果對(duì)于較小的表，不會(huì)造成顯著地影響）

以上就是MySQL性能優(yōu)化19個(gè)要點(diǎn)解析，希望對(duì)大家優(yōu)化MySQL性能有所幫助。

最新評(píng)論