當(dāng)我們?nèi)ピO(shè)計(jì)數(shù)據(jù)庫表結(jié)構(gòu)债热，對操作數(shù)據(jù)庫時(shí)（尤其是查表時(shí)的SQL語句）藐不，我們都需要注意數(shù)據(jù)操作的性能浅乔。這里，我們不會講過多的SQL語句的優(yōu)化礁竞，而只是針對MySQL這一Web應(yīng)用最多的數(shù)據(jù)庫糖荒。希望下面的這些優(yōu)化技巧對你有用。

• 為查詢緩存優(yōu)化你的查詢

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

這里最主要的問題是红碑，對于程序員來說舞吭，這個(gè)事情是很容易被忽略的。因?yàn)槲錾海覀兡承┎樵冋Z句會讓MySQL不使用緩存羡鸥。請看下面的示例：

// 查詢緩存不開啟 
$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的查詢緩存對這個(gè)函數(shù)不起作用忠寻。所以兄春，像 NOW() 和 RAND() 或是其它的諸如此類的SQL函數(shù)都不會開啟查詢緩存，因?yàn)檫@些函數(shù)的返回是會不定的易變的锡溯。所以赶舆，你所需要的就是用一個(gè)變量來代替MySQL的函數(shù)，從而開啟緩存祭饭。

• EXPLAIN 你的 SELECT 查詢

使用 EXPLAIN 關(guān)鍵字可以讓你知道MySQL是如何處理你的SQL語句的芜茵。這可以幫你分析你的查詢語句或是表結(jié)構(gòu)的性能瓶頸。

EXPLAIN 的查詢結(jié)果還會告訴你你的索引主鍵被如何利用的倡蝙，你的數(shù)據(jù)表是如何被搜索和排序的……等等九串，等等。

挑一個(gè)你的SELECT語句（推薦挑選那個(gè)最復(fù)雜的寺鸥，有多表聯(lián)接的）猪钮，把關(guān)鍵字EXPLAIN加到前面。你可以使用phpmyadmin來做這個(gè)事胆建。然后烤低，你會看到一張表格。下面的這個(gè)示例中笆载，我們忘記加上了group_id索引扑馁，并且有表聯(lián)接：

Paste_Image.png

當(dāng)我們?yōu)?group_id 字段加上索引后：

Paste_Image.png

• 當(dāng)只要一行數(shù)據(jù)時(shí)使用 LIMIT 1

當(dāng)你查詢表的有些時(shí)候涝登，你已經(jīng)知道結(jié)果只會有一條結(jié)果雄家，但因?yàn)槟憧赡苄枰etch游標(biāo)，或是你也許會去檢查返回的記錄數(shù)胀滚。

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

下面的示例褐荷，只是為了找一下是否有“中國”的用戶勾效，很明顯，后面的會比前面的更有效率叛甫。（請注意层宫，第一條中是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) { 
// ... 
}

• 為搜索字段建索引

索引并不一定就是給主鍵或是唯一的字段其监。如果在你的表中萌腿，有某個(gè)字段你總要會經(jīng)常用來做搜索，那么抖苦，請為其建立索引吧毁菱。

Paste_Image.png

從上圖你可以看到那個(gè)搜索字串 “last_name LIKE 'a%'”，一個(gè)是建了索引锌历，一個(gè)是沒有索引贮庞，性能差了4倍左右。

另外究西，你應(yīng)該也需要知道什么樣的搜索是不能使用正常的索引的窗慎。例如，當(dāng)你需要在一篇大的文章中搜索一個(gè)詞時(shí)卤材，如： “WHERE post_content LIKE '%apple%'”遮斥，索引可能是沒有意義的。你可能需要使用MySQL全文索引 或是自己做一個(gè)索引（比如說：搜索關(guān)鍵詞或是Tag什么的）

• 在Join表的時(shí)候使用相當(dāng)類型的例扇丛，并將其索引

如果你的應(yīng)用程序有很多 JOIN 查詢术吗，你應(yīng)該確認(rèn)兩個(gè)表中Join的字段是被建過索引的。這樣帆精，MySQL內(nèi)部會啟動為你優(yōu)化Join的SQL語句的機(jī)制藐翎。

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

// 在state中查找company 
$r = mysql_query("SELECT company_name FROM users 
LEFT JOIN companies ON (users.state = companies.state) 
WHERE users.id = $user_id"); 

// 兩個(gè) state 字段應(yīng)該是被建過索引的整吆，而且應(yīng)該是相當(dāng)?shù)念愋凸澳欤嗤淖址?

• 千萬不要 ORDER BY RAND()

想打亂返回的數(shù)據(jù)行辉川？隨機(jī)挑一個(gè)數(shù)據(jù)？真不知道誰發(fā)明了這種用法拴测，但很多新手很喜歡這樣用乓旗。但你確不了解這樣做有多么可怕的性能問題。

如果你真的想把返回的數(shù)據(jù)行打亂了集索，你有N種方法可以達(dá)到這個(gè)目的屿愚。這樣使用只讓你的數(shù)據(jù)庫的性能呈指數(shù)級的下降。這里的問題是：MySQL會不得不去執(zhí)行RAND()函數(shù)（很耗CPU時(shí)間）务荆，而且這是為了每一行記錄去記行妆距，然后再對其排序。就算是你用了Limit 1也無濟(jì)于事（因?yàn)橐判颍?/p>

下面的示例是隨機(jī)挑一條記錄：

// 千萬不要這樣做： 
$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");

• **避免 SELECT * **

從數(shù)據(jù)庫里讀出越多的數(shù)據(jù)函匕，那么查詢就會變得越慢娱据。并且，如果你的數(shù)據(jù)庫服務(wù)器和WEB服務(wù)器是兩臺獨(dú)立的服務(wù)器的話盅惜，這還會增加網(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']}";

• 永遠(yuǎn)為每張表設(shè)置一個(gè)ID

我們應(yīng)該為數(shù)據(jù)庫里的每張表都設(shè)置一個(gè)ID做為其主鍵咽安，而且最好的是一個(gè)INT型的（推薦使用UNSIGNED），并設(shè)置上自動增加的AUTO_INCREMEN標(biāo)志蓬推。

就算是你users表有一個(gè)主鍵叫“email”的字段妆棒，你也別讓它成為主鍵。使用VARCHAR類型來當(dāng)主鍵會使用得性能下降沸伏。另外糕珊，在你的程序中，你應(yīng)該使用表的ID來構(gòu)造你的數(shù)據(jù)結(jié)構(gòu)毅糟。

而且红选，在MySQL數(shù)據(jù)引擎下，還有一些操作需要使用主鍵姆另，在這些情況下喇肋，主鍵的性能和設(shè)置變得非常重要，比如迹辐，集群蝶防，分區(qū)……

在這里，只有一個(gè)情況是例外明吩，那就是“關(guān)聯(lián)表”的“外鍵”间学，也就是說，這個(gè)表的主鍵，通過若干個(gè)別的表的主鍵構(gòu)成低葫。我們把這個(gè)情況叫做“外鍵”详羡。比如：有一個(gè)“學(xué)生表”有學(xué)生的ID，有一個(gè)“課程表”有課程ID嘿悬，那么实柠，“成績表”就是“關(guān)聯(lián)表”了，其關(guān)聯(lián)了學(xué)生表和課程表善涨，在成績表中窒盐，學(xué)生ID和課程ID叫“外鍵”其共同組成主鍵。

• 使用 ENUM 而不是 VARCHAR

ENUM 類型是非城牛快和緊湊的登钥。在實(shí)際上畔师，其保存的是 TINYINT，但其外表上顯示為字符串。這樣一來疮蹦，用這個(gè)字段來做一些選項(xiàng)列表變得相當(dāng)?shù)耐昝馈?/p>

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

MySQL也有一個(gè)“建議”（見第十條）告訴你怎么去重新組織你的表結(jié)構(gòu)放前。當(dāng)你有一個(gè)VARCHAR字段時(shí)忿磅，這個(gè)建議會告訴你把其改成ENUM類型。使用 PROCEDURE ANALYSE()你可以得到相關(guān)的建議凭语。

• 從 PROCEDURE ANALYSE() 取得建議

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

例如炒辉，如果你創(chuàng)建了一個(gè)INT字段作為你的主鍵豪墅，然而并沒有太多的數(shù)據(jù)，那么黔寇，PROCEDURE ANALYSE()會建議你把這個(gè)字段的類型改成 MEDIUMINT 但校。或是你使用了一個(gè)VARCHAR字段啡氢，因?yàn)閿?shù)據(jù)不多状囱，你可能會得到一個(gè)讓你把它改成 ENUM 的建議术裸。這些建議，都是可能因?yàn)閿?shù)據(jù)不夠多亭枷，所以決策做得就不夠準(zhǔn)袭艺。

在phpmyadmin里，你可以在查看表時(shí)叨粘，點(diǎn)擊 “Propose table structure” 來查看這些建議

Paste_Image.png

一定要注意猾编，這些只是建議，只有當(dāng)你的表里的數(shù)據(jù)越來越多時(shí)升敲，這些建議才會變得準(zhǔn)確答倡。一定要記住，你才是最終做決定的人驴党。

• 盡可能的使用 NOT NULL

除非你有一個(gè)很特別的原因去使用NULL值瘪撇，你應(yīng)該總是讓你的字段保持NOT NULL。這看起來好像有點(diǎn)爭議港庄，請往下看倔既。

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

不要以為 NULL 不需要空間安皱，其需要額外的空間，并且率翅，在你進(jìn)行比較的時(shí)候练俐，你的程序會更復(fù)雜。 當(dāng)然冕臭，這里并不是說你就不能使用NULL了腺晾，現(xiàn)實(shí)情況是很復(fù)雜的，依然會有些情況下辜贵，你需要使用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.” *

• Prepared Statements

Prepared Statements很像存儲過程，是一種運(yùn)行在后臺的SQL語句集合托慨，我們可以從使用 prepared statements 獲得很多好處鼻由，無論是性能問題還是安全問題。

Prepared Statements可以檢查一些你綁定好的變量，這樣可以保護(hù)你的程序不會受到“SQL注入式”攻擊蕉世。當(dāng)然蔼紧，你也可以手動地檢查你的這些變量，然而狠轻，手動的檢查容易出問題奸例，而且很經(jīng)常會被程序員忘了。當(dāng)我們使用一些framework或是ORM的時(shí)候向楼，這樣的問題會好一些查吊。

在性能方面，當(dāng)一個(gè)相同的查詢被使用多次的時(shí)候湖蜕，這會為你帶來可觀的性能優(yōu)勢逻卖。你可以給這些Prepared Statements定義一些參數(shù)，而MySQL只會解析一次昭抒。

雖然最新版本的MySQL在傳輸Prepared Statements是使用二進(jìn)制形勢评也，所以這會使得網(wǎng)絡(luò)傳輸非常有效率。

當(dāng)然戈鲁，也有一些情況下仇参，我們需要避免使用Prepared Statements嘹叫，因?yàn)槠洳恢С植樵兙彺嫫诺睢５珦?jù)說版本5.1后支持了。

在PHP中要使用prepared statements罩扇，你可以查看其使用手冊：mysqli 擴(kuò)展 或是使用數(shù)據(jù)庫抽象層婆芦，如： PDO.

// 創(chuàng)建 prepared statement 
if ($stmt = $mysqli->prepare("SELECT username FROM user WHERE state=?")) { 

// 綁定參數(shù) 
$stmt->bind_param("s", $state); 

// 執(zhí)行 
$stmt->execute(); 

// 綁定結(jié)果 
$stmt->bind_result($username); 

// 移動游標(biāo) 
$stmt->fetch(); 

printf("%s is from %s\n", $username, $state); 

$stmt->close(); 
}

• 無緩沖的查詢

正常的情況下，當(dāng)你在當(dāng)你在你的腳本中執(zhí)行一個(gè)SQL語句的時(shí)候喂饥，你的程序會停在那里直到?jīng)]這個(gè)SQL語句返回消约，然后你的程序再往下繼續(xù)執(zhí)行。你可以使用無緩沖查詢來改變這個(gè)行為员帮。

關(guān)于這個(gè)事情或粮，在PHP的文檔中有一個(gè)非常不錯(cuò)的說明： mysql_unbuffered_query() 函數(shù)：

*“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()發(fā)送一個(gè)SQL語句到MySQL而并不像mysql_query()一樣去自動fetch和緩存結(jié)果捞高。這會相當(dāng)節(jié)約很多可觀的內(nèi)存氯材，尤其是那些會產(chǎn)生大量結(jié)果的查詢語句，并且硝岗，你不需要等到所有的結(jié)果都返回氢哮，只需要第一行數(shù)據(jù)返回的時(shí)候，你就可以開始馬上開始工作于查詢結(jié)果了型檀。

然而冗尤，這會有一些限制。因?yàn)槟阋窗阉行卸甲x走，或是你要在進(jìn)行下一次的查詢前調(diào)用mysql_free_result()清除結(jié)果裂七。而且皆看，mysql_num_rows()或mysql_data_seek()將無法使用。所以背零，是否使用無緩沖的查詢你需要仔細(xì)考慮悬蔽。

• 把IP地址存成 UNSIGNED INT

很多程序員都會創(chuàng)建一個(gè)VARCHAR(15)字段來存放字符串形式的IP而不是整形的IP。如果你用整形來存放捉兴，只需要4個(gè)字節(jié)蝎困，并且你可以有定長的字段。而且倍啥，這會為你帶來查詢上的優(yōu)勢禾乘，尤其是當(dāng)你需要使用這樣的WHERE條件：IP between ip1 and ip2。

我們必需要使用UNSIGNED INT虽缕，因?yàn)?IP地址會使用整個(gè)32位的無符號整形始藕。

而你的查詢，你可以使用INET_ATON()來把一個(gè)字符串IP轉(zhuǎn)成一個(gè)整形氮趋，并使用INET_NTOA()把一個(gè)整形轉(zhuǎn)成一個(gè)字符串IP伍派。在PHP中，也有這樣的函數(shù)ip2long()和long2ip()剩胁。

$r = "UPDATE users SET ip = INET_ATON('{$_SERVER['REMOTE_ADDR']}')  \
      WHERE user_id = $user_id";

• 固定長度的表會更快

如果表中的所有字段都是“固定長度”的诉植，整個(gè)表會被認(rèn)為是 “static” 或 “fixed-length”。 例如昵观，表中沒有如下類型的字段： VARCHAR晾腔，TEXT，BLOB啊犬。只要你包括了其中一個(gè)這些字段灼擂，那么這個(gè)表就不是“固定長度靜態(tài)表”了，這樣觉至，MySQL 引擎會用另一種方法來處理剔应。

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

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

使用“垂直分割”技術(shù)（見下一條）捧搞，你可以分割你的表成為兩個(gè)一個(gè)是定長的，一個(gè)則是不定長的狮荔。

• 垂直分割

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

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

示例二： 你有一個(gè)叫 “l(fā)ast_login” 的字段锻全，它會在每次用戶登錄時(shí)被更新狂塘。但是，每次更新時(shí)會導(dǎo)致該表的查詢緩存被清空鳄厌。所以荞胡，你可以把這個(gè)字段放到另一個(gè)表中，這樣就不會影響你對用戶 ID了嚎，用戶名泪漂，用戶角色的不停地讀取了廊营，因?yàn)椴樵兙彺鏁湍阍黾雍芏嘈阅堋?/p>

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

• 拆分大的 DELETE 或 INSERT 語句

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

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

如果你把你的表鎖上一段時(shí)間，比如30秒鐘像云，那么對于一個(gè)有很高訪問量的站點(diǎn)來說锌雀，這30秒所積累的訪問進(jìn)程/線程，數(shù)據(jù)庫鏈接迅诬，打開的文件數(shù)腋逆，可能不僅僅會讓你泊WEB服務(wù)Crash，還可能會讓你的整臺服務(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; 
} 
// 每次都要休息一會兒 
usleep(50000); 
}

• 越小的列會越快

對于大多數(shù)的數(shù)據(jù)庫引擎來說争涌，硬盤操作可能是最重大的瓶頸。所以辣恋，把你的數(shù)據(jù)變得緊湊會對這種情況非常有幫助亮垫，因?yàn)檫@減少了對硬盤的訪問解幼。

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

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

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

• 選擇正確的存儲引擎

在 MySQL 中有兩個(gè)存儲引擎 MyISAM 和 InnoDB线欲，每個(gè)引擎都有利有弊明场。酷殼以前文章《MySQL: InnoDB 還是 MyISAM?》討論和這個(gè)事情李丰。

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

InnoDB的趨勢會是一個(gè)非常復(fù)雜的存儲引擎痹筛，對于一些小的應(yīng)用莺治，它會比 MyISAM 還慢。他是它支持“行鎖” 帚稠，于是在寫操作比較多的時(shí)候，會更優(yōu)秀床佳。并且滋早，他還支持更多的高級應(yīng)用，比如：事務(wù)砌们。

下面是MySQL的手冊

target=”_blank”
MyISAM Storage Engine
InnoDB Storage Engine

• 使用一個(gè)對象關(guān)系映射器（Object Relational Mapper）

使用 ORM (Object Relational Mapper)杆麸，你能夠獲得可靠的性能增漲搁进。一個(gè)ORM可以做的所有事情，也能被手動的編寫出來昔头。但是饼问，這需要一個(gè)高級專家。

ORM 的最重要的是“Lazy Loading”揭斧，也就是說莱革，只有在需要的去取值的時(shí)候才會去真正的去做。但你也需要小心這種機(jī)制的副作用讹开，因?yàn)檫@很有可能會因?yàn)橐?chuàng)建很多很多小的查詢反而會降低性能盅视。

ORM 還可以把你的SQL語句打包成一個(gè)事務(wù)，這會比單獨(dú)執(zhí)行他們快得多得多旦万。

目前闹击，個(gè)人最喜歡的PHP的ORM是：Doctrine。

• 小心“永久鏈接”

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

PHP手冊：mysql_pconnect()

在理論上來說，這聽起來非常的不錯(cuò)丹莲。但是從個(gè)人經(jīng)驗(yàn)（也是大多數(shù)人的）上來說光坝，這個(gè)功能制造出來的麻煩事更多。因?yàn)樯模阒挥杏邢薜逆溄訑?shù)盯另，內(nèi)存問題，文件句柄數(shù)洲赵，等等鸳惯。

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

來源：http://code.tutsplus.com/tutorials/top-20-mysql-best-practices--net-7855