寫在前面：最早接觸的MySQL是在三年前，那時(shí)候MySQL還是4.x版本，很多功能都不支持，比如，存儲(chǔ)過(guò)程，視圖，觸發(fā)器，更別說(shuō)分布式事務(wù)等復(fù)雜特性了。但從5.0(2005年10月)開始，MySQL漸漸步入企業(yè)級(jí)數(shù)據(jù)庫(kù)的行列了；復(fù)制、集群、分區(qū)、分布式事務(wù)，這些企業(yè)級(jí)的特性，使得現(xiàn)在的MySQL，完全可以應(yīng)用于企業(yè)級(jí)應(yīng)用環(huán)境(很多互聯(lián)網(wǎng)公司都用其作為數(shù)據(jù)庫(kù)服務(wù)器，盡管節(jié)約成本是一個(gè)因素，但是沒有強(qiáng)大功能作后盾，則是不可想象的)。雖然，MySQL還有很多不足，比如，復(fù)制、分區(qū)的支持都十分有限、查詢優(yōu)化仍需要改進(jìn)，但是MySQL已經(jīng)是一個(gè)足夠好的DBMS了，更何況它是opensource的。這段時(shí)間沒有事，出于好奇，略微的研究了一下MySQL，積累了一些資料，欲總結(jié)出來(lái)。這些資料打算分為兩部分，上部主要討論MySQL的優(yōu)化，其中主要參考了《MySQL Manual》和《High Performance MySQL》，如果有時(shí)間，以后在下部分析一下MySQL的源碼。如果你是MySQL高手，希望你不吝賜教；如果你是新手，希望對(duì)你有用。

第一章、MySQL架構(gòu)與概念
1、MySQL的邏輯架構(gòu)

 最上面不是MySQL特有的，所有基于網(wǎng)絡(luò)的C/S的網(wǎng)絡(luò)應(yīng)用程序都應(yīng)該包括連接處理、認(rèn)證、安全管理等。
中間層是MySQL的核心，包括查詢解析、分析、優(yōu)化和緩存等。同時(shí)它還提供跨存儲(chǔ)引擎的功能，包括存儲(chǔ)過(guò)程、觸發(fā)器和視圖等。
最下面是存儲(chǔ)引擎，它負(fù)責(zé)存取數(shù)據(jù)。服務(wù)器通過(guò)storage engine API可以和各種存儲(chǔ)引擎進(jìn)行交互。

1.1、查詢優(yōu)化和執(zhí)行(Optimization and Execution)

MySQL將用戶的查詢語(yǔ)句進(jìn)行解析，并創(chuàng)建一個(gè)內(nèi)部的數(shù)據(jù)結(jié)構(gòu)——分析樹，然后進(jìn)行各種優(yōu)化，例如重寫查詢、選擇讀取表的順序，以及使用哪個(gè)索引等。查詢優(yōu)化器不關(guān)心一個(gè)表所使用的存儲(chǔ)引擎，但是存儲(chǔ)引擎會(huì)影響服務(wù)器如何優(yōu)化查詢。優(yōu)化器通過(guò)存儲(chǔ)引擎獲取一些參數(shù)、某個(gè)操作的執(zhí)行代價(jià)、以及統(tǒng)計(jì)信息等。在解析查詢之前，服務(wù)器會(huì)先訪問(wèn)查詢緩存(query cache)——它存儲(chǔ)SELECT語(yǔ)句以及相應(yīng)的查詢結(jié)果集。如果某個(gè)查詢結(jié)果已經(jīng)位于緩存中，服務(wù)器就不會(huì)再對(duì)查詢進(jìn)行解析、優(yōu)化、以及執(zhí)行。它僅僅將緩存中的結(jié)果返回給用戶即可，這將大大提高系統(tǒng)的性能。

 1.2、并發(fā)控制
MySQL提供兩個(gè)級(jí)別的并發(fā)控制：服務(wù)器級(jí)(the server level)和存儲(chǔ)引擎級(jí)(the storage engine level)。加鎖是實(shí)現(xiàn)并發(fā)控制的基本方法，MySQL中鎖的粒度：
(1)    表級(jí)鎖：MySQL獨(dú)立于存儲(chǔ)引擎提供表鎖，例如，對(duì)于ALTER TABLE語(yǔ)句，服務(wù)器提供表鎖(table-level lock)。
(2)    行級(jí)鎖：InnoDB和Falcon存儲(chǔ)引擎提供行級(jí)鎖，此外，BDB支持頁(yè)級(jí)鎖。InnoDB的并發(fā)控制機(jī)制，下節(jié)詳細(xì)討論。
另外，值得一提的是，MySQL的一些存儲(chǔ)引擎（如InnoDB、BDB）除了使用封鎖機(jī)制外，還同時(shí)結(jié)合MVCC機(jī)制，即多版本兩階段封鎖協(xié)議(Multiversion two-phrase locking protocal)，來(lái)實(shí)現(xiàn)事務(wù)的并發(fā)控制，從而使得只讀事務(wù)不用等待鎖，提高了事務(wù)的并發(fā)性。
注：并發(fā)控制是DBMS的核心技術(shù)之一(實(shí)際上，對(duì)于OS也一樣)，它對(duì)系統(tǒng)性能有著至關(guān)重要的影響，以后再詳細(xì)討論。

1.3、事務(wù)處理
MySQL中，InnoDB和BDB都支持事務(wù)處理。這里主要討論InnoDB的事務(wù)處理(關(guān)于BDB的事務(wù)處理，也十分復(fù)雜，以前曾較為詳細(xì)看過(guò)其源碼，以后有機(jī)會(huì)再討論)。
1.3.1、事務(wù)的ACID特性
事務(wù)是由一組SQL語(yǔ)句組成的邏輯處理單元，事務(wù)具有以下4個(gè)屬性，通常簡(jiǎn)稱為事務(wù)的ACID屬性(Jim Gray在《事務(wù)處理：概念與技術(shù)》中對(duì)事務(wù)進(jìn)行了詳盡的討論)。
(1)原子性（Atomicity）：事務(wù)是一個(gè)原子操作單元，其對(duì)數(shù)據(jù)的修改，要么全都執(zhí)行，要么全都不執(zhí)行。
(2)一致性（Consistent）：在事務(wù)開始和完成時(shí)，數(shù)據(jù)都必須保持一致狀態(tài)。這意味著所有相關(guān)的數(shù)據(jù)規(guī)則都必須應(yīng)用于事務(wù)的修改，以保持?jǐn)?shù)據(jù)的完整性；事務(wù)結(jié)束時(shí)，所有的內(nèi)部數(shù)據(jù)結(jié)構(gòu)（如B樹索引或雙向鏈表）也都必須是正確的。
(3)隔離性（Isolation）：數(shù)據(jù)庫(kù)系統(tǒng)提供一定的隔離機(jī)制，保證事務(wù)在不受外部并發(fā)操作影響的“獨(dú)立”環(huán)境執(zhí)行。這意味著事務(wù)處理過(guò)程中的中間狀態(tài)對(duì)外部是不可見的，反之亦然。
(4)持久性（Durable）：事務(wù)完成之后，它對(duì)于數(shù)據(jù)的修改是永久性的，即使出現(xiàn)系統(tǒng)故障也能夠保持。
1.3.2、事務(wù)處理帶來(lái)的相關(guān)問(wèn)題
由于事務(wù)的并發(fā)執(zhí)行，帶來(lái)以下一些著名的問(wèn)題：
(1)更新丟失（Lost Update）：當(dāng)兩個(gè)或多個(gè)事務(wù)選擇同一行，然后基于最初選定的值更新該行時(shí)，由于每個(gè)事務(wù)都不知道其他事務(wù)的存在，就會(huì)發(fā)生丟失更新問(wèn)題－－最后的更新覆蓋了由其他事務(wù)所做的更新。
(2)臟讀（Dirty Reads）：一個(gè)事務(wù)正在對(duì)一條記錄做修改，在這個(gè)事務(wù)完成并提交前，這條記錄的數(shù)據(jù)就處于不一致狀態(tài)；這時(shí)，另一個(gè)事務(wù)也來(lái)讀取同一條記錄，如果不加控制，第二個(gè)事務(wù)讀取了這些“臟”數(shù)據(jù)，并據(jù)此做進(jìn)一步的處理，就會(huì)產(chǎn)生未提交的數(shù)據(jù)依賴關(guān)系。這種現(xiàn)象被形象地叫做"臟讀"。
(3)不可重復(fù)讀（Non-Repeatable Reads）：一個(gè)事務(wù)在讀取某些數(shù)據(jù)后的某個(gè)時(shí)間，再次讀取以前讀過(guò)的數(shù)據(jù)，卻發(fā)現(xiàn)其讀出的數(shù)據(jù)已經(jīng)發(fā)生了改變、或某些記錄已經(jīng)被刪除了！這種現(xiàn)象就叫做“不可重復(fù)讀”。
(4)幻讀（Phantom Reads）：一個(gè)事務(wù)按相同的查詢條件重新讀取以前檢索過(guò)的數(shù)據(jù)，卻發(fā)現(xiàn)其他事務(wù)插入了滿足其查詢條件的新數(shù)據(jù)，這種現(xiàn)象就稱為“幻讀”。
1.3.3、事務(wù)的隔離性
SQL2標(biāo)準(zhǔn)定義了四個(gè)隔離級(jí)別。定義語(yǔ)句如下：
SET TRANSACTION ISOLATION LEVEL
[READ UNCOMMITTED |
READ COMMITTED  |
REPEATABLE READ  |
SERIALIZABLE ]
這與Jim Gray所提出的隔離級(jí)別有點(diǎn)差異。其中READ UNCOMMITTED即Jim的10（瀏覽）；READ COMMITTED即20，游標(biāo)穩(wěn)定性；REPEATABLE READ為2.99990隔離(沒有幻像保護(hù))；SERIALIZABLE隔離級(jí)別為30，完全隔離。SQL2標(biāo)準(zhǔn)默認(rèn)為完全隔離(30)。各個(gè)級(jí)別存在問(wèn)題如下：

各個(gè)具體數(shù)據(jù)庫(kù)并不一定完全實(shí)現(xiàn)了上述4個(gè)隔離級(jí)別，例如，Oracle只提供READ COMMITTED和Serializable兩個(gè)標(biāo)準(zhǔn)隔離級(jí)別，另外還提供自己定義的Read only隔離級(jí)別；SQL Server除支持上述ISO/ANSI SQL92定義的4個(gè)隔離級(jí)別外，還支持一個(gè)叫做“快照”的隔離級(jí)別，但嚴(yán)格來(lái)說(shuō)它是一個(gè)用MVCC實(shí)現(xiàn)的Serializable隔離級(jí)別。MySQL 支持全部4個(gè)隔離級(jí)別，其默認(rèn)級(jí)別為Repeatable read，但在具體實(shí)現(xiàn)時(shí)，有一些特點(diǎn)，比如在一些隔離級(jí)別下是采用MVCC一致性讀。國(guó)產(chǎn)數(shù)據(jù)庫(kù)DM也支持所有級(jí)別，其默認(rèn)級(jí)別為READ COMMITTED。
 

1.3.4、InnoDB的鎖模型
InnoDB的行級(jí)鎖有兩種類型：
(1)共享鎖(shared lock，S)：允許一個(gè)事務(wù)去讀一行，阻止其他事務(wù)獲得相同數(shù)據(jù)集的排他鎖。
(2)排它鎖(exclusive lock，X)：允許獲得排它鎖的事務(wù)更新數(shù)據(jù)，阻止其他事務(wù)取得相同數(shù)據(jù)集的共享讀鎖和排他寫鎖。
此外，InnoDB支持多粒度加鎖(multiple granularity locking)，從而允許對(duì)記錄和表同時(shí)加鎖。為此，InnoDB引入意向鎖(intention locks)，意向鎖是針對(duì)表的：
(1)意向共享鎖（IS）：事務(wù)打算給數(shù)據(jù)行加行共享鎖，事務(wù)在給一個(gè)數(shù)據(jù)行加共享鎖前必須先取得該表的IS鎖。
(2)意向排他鎖（IX）：事務(wù)打算給數(shù)據(jù)行加行排他鎖，事務(wù)在給一個(gè)數(shù)據(jù)行加排他鎖前必須先取得該表的IX鎖。
例如，SELECT ... LOCK IN SHARE MODE加IS鎖，SELECT ... FOR UPDATE加IX鎖，意向鎖的規(guī)則如下：
(1)事務(wù)在對(duì)表T中的記錄獲取S鎖前，先要獲取表T的IS鎖或者更強(qiáng)的鎖；
(2)事務(wù)在獲取表T中記錄的X鎖前，先要獲取表T的IX鎖。
InnoDB的鎖相容性矩陣：

 如果一個(gè)事務(wù)請(qǐng)求的鎖模式與當(dāng)前的鎖兼容，InnoDB就將請(qǐng)求的鎖授予該事務(wù)；反之，如果兩者不兼容，該事務(wù)就要等待鎖釋放。意向鎖只會(huì)阻塞其它事務(wù)對(duì)表的請(qǐng)求，例如，LOCK TABLES …WRITE，意向鎖的主要目的是表明該事務(wù)將要或者正在對(duì)表中的記錄加鎖。使用封鎖機(jī)制來(lái)進(jìn)行并發(fā)控制，一個(gè)比較重要的問(wèn)題就是死鎖。
來(lái)看一個(gè)死鎖的例子：

例1-1

 1.3.5、一致性非阻塞讀
一致性讀是MySQL的重要特點(diǎn)之一，InnoDB通過(guò)MVCC機(jī)制表示數(shù)據(jù)庫(kù)某一時(shí)刻的查詢快照，查詢可以看該時(shí)刻之前提交的事務(wù)所做的改變，但是不能看到該時(shí)刻之后或者未提交事務(wù)所做的改變。但是，查詢可以看到同一事務(wù)中之前語(yǔ)句所做的改變，例如：

例1-2

 如果事務(wù)的隔離級(jí)別為REPEATABLE READ（默認(rèn)），同一個(gè)事務(wù)中的所有一致性讀都是讀的事務(wù)的第一次讀操作創(chuàng)建的快照。你可以提交當(dāng)前事務(wù)，然后在新的查詢中即可看到最新的快照，如上所示。
如果事務(wù)的隔離級(jí)別為READ COMMITTED，一致性讀只是對(duì)事務(wù)內(nèi)部的讀操作和它自己的快照而言的，結(jié)果如下：

例1-3

 注意，session 2發(fā)生了不可重復(fù)讀。
當(dāng)InnoDB在READ COMMITTED 和REPEATABLE READ隔離級(jí)別下處理SELECT語(yǔ)句時(shí)，一致性讀是默認(rèn)的模式。一致性讀不會(huì)對(duì)表加任何鎖，所以，其它連接可以同時(shí)改變表。
假設(shè)事務(wù)處于REPEATABLE READ級(jí)別，當(dāng)你正在進(jìn)行一致性讀時(shí)，InnoDB根據(jù)查詢看到的數(shù)據(jù)給你一個(gè)時(shí)間點(diǎn)。如果其它的事務(wù)在該時(shí)間點(diǎn)之后刪除一行，且提交事務(wù)，你不會(huì)看到行已經(jīng)被刪除，插入和更新操作一樣。但是，InnoDB與其它DBMS的不同是，在REPEATABLE READ隔離級(jí)別下并不會(huì)造成幻像。
一致性讀不與DROP TABLE 或者 ALTER TABLE一起工作。
在nodb_locks_unsafe_for_binlog變量被設(shè)置或者事務(wù)的隔離級(jí)別不是SERIALIZABLE的情況下，InnoDB對(duì)于沒有指定FOR UPDATE 或 LOCK IN SHARE MODE的INSERT INTO ... SELECT, UPDATE ... (SELECT), 和CREATE TABLE ... SELECT語(yǔ)句使用一致性讀，在這種情況下，查詢語(yǔ)句不會(huì)對(duì)表中的元組加鎖。否則，InnoDB將使用鎖。

1.3.6、SELECT ... FOR UPDATE和SELECT ... LOCK IN SHARE MODE的加鎖讀(locking read)
在一些場(chǎng)合，一致性讀并不是很方便，此時(shí)，可以用加鎖讀。InnoDB支持兩種加鎖讀：
(1)    SELECT ... LOCK IN SHARE MODE：對(duì)讀取的元組加S鎖。
(2)    SELECT ... FOR UPDATE：在掃描索引記錄的過(guò)程中，會(huì)阻塞其它連接的SELECT ...LOCK IN SHARE MODE和一定事務(wù)隔離級(jí)別下的讀操作。
InnoDB使用兩階段封鎖協(xié)議，事務(wù)直到提交或回滾時(shí)才會(huì)釋放所有的鎖，這都是系統(tǒng)自動(dòng)執(zhí)行的。此外，MySQL支持LOCK TABLES和UNLOCK TABLES，但這些都是在服務(wù)器層實(shí)現(xiàn)的，而不是在存儲(chǔ)引擎。它們有用處，但是不能取代存儲(chǔ)引擎完成事務(wù)處理，如果你需要事務(wù)功能，請(qǐng)使用事務(wù)型存儲(chǔ)引擎。
來(lái)考慮locking read的應(yīng)用，假設(shè)你要在表child插入一個(gè)新的元組，并保證child中的記錄在表parent有一條父記錄。如果你用一致性讀來(lái)讀parent表，確實(shí)可以將要插入的child row的parent row，但是可以安全的插入嗎？不，因?yàn)樵谀阕xparent表時(shí)，其它連接可能已經(jīng)刪除該記錄。（一致性讀是針對(duì)事務(wù)內(nèi)而言的，對(duì)于數(shù)據(jù)庫(kù)的狀態(tài)，它應(yīng)該叫做“不一致性讀”）
此時(shí)，就可以使用SELECT LOCK IN SHARE MODE，它會(huì)對(duì)讀取的元組加S鎖，從而防止其它連接刪除或更新元組。另外，如果你想在查詢的同時(shí)，進(jìn)行更新操作，可以使用SELECT ... FOR UPDATE，它讀取最新的數(shù)據(jù)，然后對(duì)讀到的元組加X鎖。此時(shí)，使用SELECT ... LOCK IN SHARE MODE不是一個(gè)好主意，因?yàn)榇藭r(shí)如果有兩個(gè)事務(wù)進(jìn)行這樣的操作，就會(huì)造成死鎖。
注：SELECT ... FOR UPDATE僅在自動(dòng)提交關(guān)閉(即手動(dòng)提交)時(shí)才會(huì)對(duì)元組加鎖，而在自動(dòng)提交時(shí)，符合條件的元組不會(huì)被加鎖。

1.3.7、記錄鎖(record lok)、間隙鎖(gap lock)和后碼鎖(next-key lock)
InnoDB有以下幾種行級(jí)鎖：
(1)記錄鎖：對(duì)索引記錄(index records)加鎖，InnoDB行級(jí)鎖是通過(guò)給索引的索引項(xiàng)加鎖來(lái)實(shí)現(xiàn)的，而不是對(duì)記錄實(shí)例本身加鎖。如果表沒有定義索引，InnoDB創(chuàng)建一個(gè)隱藏的聚簇索引，然后用它來(lái)實(shí)現(xiàn)記錄加鎖（關(guān)于索引與加鎖之間的關(guān)系的詳細(xì)介紹請(qǐng)看下一章）。
(2)間隙鎖：對(duì)索引記錄之間的區(qū)間，或者第一個(gè)索引記錄之前的區(qū)間和最后一個(gè)索引之后的區(qū)間加鎖。
(3)后碼鎖：對(duì)索引記錄加記錄鎖，且對(duì)索引記錄之前的區(qū)間加鎖。
默認(rèn)情況下，InnoDB的事務(wù)工作在REPEATABLE READ的隔離級(jí)別，而且系統(tǒng)變量innodb_locks_unsafe_for_binlog為關(guān)閉狀態(tài)。此時(shí)，InnoDB使用next-key鎖進(jìn)行查找和索引掃描，從而達(dá)到防止“幻像”的目的。
Next-key鎖是記錄鎖和間隙的結(jié)合體。當(dāng)InnoDB查找或掃描表的索引時(shí)，對(duì)它遇到的索引記錄加S鎖或者X鎖，所以，行級(jí)鎖(row-level lock)實(shí)際上就是索引記錄鎖(index-record lock)；此外，它還對(duì)索引記錄之前的區(qū)間加鎖。也就是說(shuō)，next-key鎖是索引記錄鎖，外加索引記錄之前的區(qū)間的間隙鎖。如果一個(gè)連接對(duì)索引中的記錄R持有S或X鎖，其它的連接不能按照索引的順序在R之前的區(qū)間插入一個(gè)索引記錄。
假設(shè)索引包含以下值：10, 11,13和20，則索引的next-key鎖會(huì)覆蓋以下區(qū)間(“(”表示不包含，“[”表示包含)：
(negative infinity, 10]
(10, 11]
(11, 13]
(13, 20]
(20, positive infinity)
對(duì)于最后一個(gè)區(qū)間，next-key鎖將鎖住索引最大值以上的區(qū)間，上界虛記錄(“supremum” pseudo-record)的值比索引中的任何值都大，其實(shí)，上界不是一個(gè)真實(shí)的索引記錄，所以，next-lock將對(duì)索引的最大值之后的區(qū)間加鎖。

間隙鎖對(duì)查詢唯一索引中的唯一值是沒有必要的，例如，id列有唯一索引，則下面的查詢僅對(duì)id=100的元組加索引記錄鎖(index-record lock)，而不管其它連接是否在之前的區(qū)間插入元組。
SELECT * FROM child WHERE id = 100;
如果id沒有索引，或者非唯一索引，則語(yǔ)句會(huì)鎖住之前的空間。

例1-4

Session 1

Session 2

mysql> create unique index i_index on t(i);

Query OK, 0 rows affected (0.19 sec)

Records: 0 Duplicates: 0 Warnings: 0

mysql> select * from t;

+------+

| i    |

+------+

|    4 |

|   10 |

+------+

2 rows in set (0.00 sec)

mysql> set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

mysql> select i from t where i =10 lock in share mode;

+------+

| i    |

+------+

|   10 |

+------+

1 row in set (0.00 sec)

mysql> insert into t(i) values(9);

Query OK, 1 row affected (0.03 sec)

mysql> select * from t;

+------+

| i    |

+------+

|    4 |

|    9 |

|   10 |

+------+

3 rows in set (0.00 sec)

 上例中，產(chǎn)生了幻像問(wèn)題。如果將唯一查詢變成范圍查詢，結(jié)果如下(接上例的索引)：

例1-5

 可以看到，session 2 的next-key使得在i=4之前的區(qū)間和之后的插入都被阻塞。
另外，如果刪除索引i_index，則結(jié)果如下：

例1-6

 另外，針對(duì)插入(INSERT)操作，只要多個(gè)事務(wù)不會(huì)在同一索引區(qū)間的同一個(gè)位置插入記錄，它們就不用互相等待，這種情況可以稱為插入意向間隙鎖(insertion intention gap lock)。例如，索引記錄的值為4和7，兩個(gè)獨(dú)立的事務(wù)分別插入5和6，僅管它們都持有4—7之間的間隙鎖，但是它們不會(huì)相互阻塞。這可以提高事務(wù)的并發(fā)性。

例1-7

 間隙鎖是可以顯示關(guān)閉的，如果你將事務(wù)的隔離級(jí)別設(shè)為READ COMMITTED，或者打開innodb_locks_unsafe_for_binlog系統(tǒng)變量，間隙鎖就會(huì)關(guān)閉。在這種情況下，查找或掃描索引僅會(huì)進(jìn)行外鍵約束檢查和重復(fù)鍵值檢查。
此外，READ COMMITTED隔離級(jí)別和關(guān)閉nodb_locks_unsafe_for_binlog還有另外一個(gè)負(fù)作用：MySQL會(huì)釋放掉不匹配Where條件的記錄鎖。例如，對(duì)于UPDATE語(yǔ)句，InnoDB只能進(jìn)行“半一致性(semi_consistent)讀”，所以，它會(huì)返回最新提交事務(wù)所做改變，從而產(chǎn)生不可重復(fù)讀和幻像問(wèn)題。

1.3.8、使用next-key lock防止幻像問(wèn)題
例1-4展示了一個(gè)幻像問(wèn)題。使用next-key鎖的select語(yǔ)句可以解決幻像問(wèn)題，但例1-4的之所以會(huì)產(chǎn)生總是在于唯一索引，使得select語(yǔ)句沒有使用gap lock，而只使用了index-record lock。

1.4、存儲(chǔ)引擎
插件式存儲(chǔ)引擎是MySQL最重要特性之一，也是最不同于其它DBMS的地方。MySQL支持很多存儲(chǔ)引擎，以適用于不同的應(yīng)用需求，常用的包括MyISAM、InnoDB、BDB、MEMORY、MERGE、NDB Cluster等。其中，BDB和NDB Cluster提供事務(wù)支持。
MySQL默認(rèn)的存儲(chǔ)引擎為MyISAM，當(dāng)然，創(chuàng)建表的時(shí)候可以指定其它的存儲(chǔ)引擎，你可以在同一個(gè)數(shù)據(jù)庫(kù)中對(duì)不同的表使用不同的存儲(chǔ)引擎(這是非常強(qiáng)大而獨(dú)特的特性)。可以通過(guò)SHOW TABLE STATUS命令查詢表所使用的存儲(chǔ)引擎，例如，查看mysql數(shù)據(jù)庫(kù)的user表：

 Name：表的名稱；
Engine：表使用的存儲(chǔ)引擎；
Row_format：記錄的格式。MyISAM支持三種不同的存儲(chǔ)格式：靜態(tài)(固定長(zhǎng)度)表(默認(rèn)格式)、動(dòng)態(tài)表及壓縮表。靜態(tài)表的字段都是固定長(zhǎng)度的，例如CHAR和INTEGER；動(dòng)態(tài)表的字段可以是變長(zhǎng)的，例如，VARCHAR或者BLOB。
Rows：表中記錄的數(shù)量。
Avg_row_length：記錄的平均長(zhǎng)度(字節(jié)數(shù))；
Data_length：表中數(shù)據(jù)的全部字節(jié)數(shù)；
Max_data_length：表中數(shù)據(jù)最大的字節(jié)數(shù)；
Index_length：索引消耗的磁盤空間；
Data_free：對(duì)于MyISAM表，表示已經(jīng)分配但還沒有使用的空間；該空間包含以前刪除的記錄留下的空間，可以被INSERT操作重用。
Auto_increment：下一個(gè)自增的值。
Check_time：上次使用CHECK TABLE或myisamchk檢查表的時(shí)間。

1.4.1、MyISAM
1.4.1.1、存儲(chǔ)
MySQL的默認(rèn)存儲(chǔ)引擎，性能與功能的折中，包括全文索引(full-text index)、數(shù)據(jù)壓縮，支持空間(GIS)數(shù)據(jù)，但是，不支持事務(wù)和行級(jí)鎖。一般來(lái)說(shuō)，MyISAM更適用于大量查詢操作。如果你有大量的插入、刪除操作，你應(yīng)該選擇InnoDB。
每個(gè)表包含3個(gè)文件：
(1).frm：表定義文件，對(duì)于其它存儲(chǔ)引擎也一樣。
(2).MYD文件：數(shù)據(jù)文件。
(3).MYI文件：索引文件。
可以在創(chuàng)建表時(shí)通過(guò)DATA DIRECTORY和INDEX DIRECTORY為數(shù)據(jù)文件和索引文件指定路徑，它們可以位于不同目錄。另外，MyISAM的存儲(chǔ)格式是跨平臺(tái)的，你可以將數(shù)據(jù)文件和索引文件從Intel平臺(tái)拷貝到PPC或者SPARC平臺(tái)。
5.0中，MyISAM的變長(zhǎng)記錄表默認(rèn)處理256TB數(shù)據(jù)，使用6字節(jié)的指針來(lái)指向數(shù)據(jù)記錄；而之前的版本使用默認(rèn)的4字節(jié)指針，所以只能處理4GB數(shù)據(jù)。所有的版本都可以將指針增加到8字節(jié)指針，如果你想改變MyISAM表的指針的大小，可以通過(guò)設(shè)置MAX_ROWS和AVG_ROW_LENGTH來(lái)實(shí)現(xiàn)：
CREATE TABLE mytable (
   a    INTEGER  NOT NULL PRIMARY KEY,
   b    CHAR(18) NOT NULL
) MAX_ROWS = 1000000000 AVG_ROW_LENGTH = 32;
上面的例子中，MySQL將至少可以存儲(chǔ)32GB的數(shù)據(jù)。可以查看一下表的信息：

可以看到，Create_options列出了創(chuàng)建時(shí)的選項(xiàng)，而且該表的最大的數(shù)據(jù)量為91GB。你可以用ALTER TABLE來(lái)改變指針的大小，但是那會(huì)導(dǎo)致表和索引的重建，這會(huì)花費(fèi)很長(zhǎng)的時(shí)間。

1.4.1.2、MyISAM的特性
(1)鎖與并發(fā)性：MyISAM只有表級(jí)鎖，不支持行級(jí)鎖。所以不適合于大量的寫操作，但是它支持并發(fā)插入(concurrent inserts)，這是一個(gè)非常重要且有用的特性。
(2)自動(dòng)修復(fù)：MySQL支持自動(dòng)檢查和修復(fù)MyISAM表。
(3)手動(dòng)修復(fù)：你可以使用CHECK TABLE檢查表的狀態(tài)，并用REPAIR TABLE修復(fù)表。
(4)索引：你可以為BLOB和TEXT的前500個(gè)字符創(chuàng)建索引。而且，MyISAM還支持全文索引，但僅限于CHAR、VARCHAR、和TEXT列。
(5)延遲鍵寫(Delayed key writes)：如果創(chuàng)建MyISAM表時(shí)指定DELAY_KEY_WRITE，MySQL在查詢結(jié)束時(shí)，不會(huì)將改變的索引數(shù)據(jù)寫入磁盤，而將修改保存在key buffer中。只有要改變緩存或者關(guān)閉表時(shí)，才會(huì)把索引數(shù)據(jù)刷入磁盤。

1.4.2、InnoDB
InnoDB是一個(gè)高性能的事務(wù)存儲(chǔ)引擎，此外，BDB也支持事務(wù)處理(關(guān)于BDB，以前曾較為詳細(xì)的閱讀過(guò)其源碼，以后有時(shí)間再討論)，它有以下一些特點(diǎn)：
1.4.2.1、表空間
InnoDB存儲(chǔ)表和索引有兩種方式：
(1)共享表空間存儲(chǔ)：這種方式下，表的定義位于.frm文件中，數(shù)據(jù)和索引保存在innodb_data_home_dir和innodb_data_file_path指定的表空間中。
(2)多表空間存儲(chǔ)：表的定義仍位于.frm文件，但是，每個(gè)InnoDB表和它的索引在它自己的文件(.idb)中，每個(gè)表有它自己的表空間。
對(duì)那些想把特定表格移到分離物理磁盤的用戶，或者那些希望快速恢復(fù)單個(gè)表的備份而無(wú)須打斷其余InnoDB表的使用的用戶，使用多表空間會(huì)是有益的。你可以往my.cnf的[mysqld]節(jié)添加下面行來(lái)允許多表空間：
[mysqld]
innodb_file_per_table
重啟服務(wù)器之后，InnoDB存儲(chǔ)每個(gè)新創(chuàng)建的表到表格所屬于的數(shù)據(jù)庫(kù)目錄下它自己的文件tbl_name.ibd里。這類似于MyISAM存儲(chǔ)引擎所做的，但MyISAM 把表分成數(shù)據(jù)文件tbl_name.MYD和索引文件tbl_name.MYI。對(duì)于InnoDB，數(shù)據(jù)和所以被一起存到.ibd文件。tbl_name.frm文件照舊依然被創(chuàng)建。
如果你從my.cnf文件刪除innodb_file_per_table行，并重啟服務(wù)器，InnoDB在共享的表空間文件里再次創(chuàng)建表。
innodb_file_per_table只影響表的創(chuàng)建。如果你用這個(gè)選項(xiàng)啟動(dòng)服務(wù)器，新表被用.ibd文件來(lái)創(chuàng)建，但是你仍舊能訪問(wèn)在共享表空間里的表。如果你刪掉這個(gè)選項(xiàng)，新表在共享表空間內(nèi)創(chuàng)建，但你仍舊可以訪問(wèn)任何用多表空間創(chuàng)建的表。
InnoDB總是需要共享表空間，.ibd文件對(duì)InnoDB不足以去運(yùn)行，共享表空間包含熟悉的ibdata文件，InnoDB把內(nèi)部數(shù)據(jù)詞典和undo日志放在這個(gè)文件中。

1.4.2.2、外鍵約束
MySQL中，支持外鍵的存儲(chǔ)引擎只有InnoDB，在創(chuàng)建外鍵時(shí)，要求被參照表必須有對(duì)應(yīng)的索引，參照表在創(chuàng)建外鍵時(shí)也會(huì)自動(dòng)創(chuàng)建對(duì)應(yīng)的索引。

1.4.2.3、MVCC與后碼鎖(next-key locking)
InnoDB將MVCC機(jī)制與next-key lock結(jié)合起來(lái)，實(shí)現(xiàn)事務(wù)的各個(gè)隔離級(jí)別，這是非常用意思的。在nodb_locks_unsafe_for_binlog變量被設(shè)置或者事務(wù)的隔離級(jí)別不是SERIALIZABLE的情況下，InnoDB對(duì)于沒有指定FOR UPDATE 或 LOCK IN SHARE MODE的INSERT INTO ... SELECT, UPDATE ... (SELECT), 和CREATE TABLE ... SELECT語(yǔ)句使用一致性讀(參照前面)，在這種情況下，查詢語(yǔ)句不會(huì)對(duì)表中的元組加鎖。否則，InnoDB將使用鎖。