從我的個(gè)人博客訪(fǎng)問(wèn)

MySQL的特性是它的存儲(chǔ)引擎架構(gòu)。

這種設(shè)計(jì)將查詢(xún)處理(Query Processing)及其他系統(tǒng)任務(wù)(Server Task) 和數(shù)據(jù)的存儲(chǔ)/提取相分離。

在使用時(shí)根據(jù)具體情況選擇存儲(chǔ)引擎。

MySQL邏輯架構(gòu)

MySQL服務(wù)器邏輯架構(gòu)圖

由上圖可以主要分為三層：

第一層架構(gòu) 主要功能：連接處理，授權(quán)認(rèn)證，安全等。

第二層架構(gòu) 大多數(shù)MySQL的核心服務(wù)都在這一層：查詢(xún)解析、分析、優(yōu)化、緩存以及所有的內(nèi)置函數(shù)(eg: 日期、時(shí)間、數(shù)學(xué)、加密等函數(shù))，所有跨存儲(chǔ)引擎的功能都在這一層實(shí)現(xiàn)：存儲(chǔ)過(guò)程、觸發(fā)器、視圖等。

第三層架構(gòu) 包含了存儲(chǔ)引擎 負(fù)責(zé)MySQL中數(shù)據(jù)的存儲(chǔ)和提取。 服務(wù)器通過(guò)API與存儲(chǔ)引擎進(jìn)行通信，API屏蔽了不同引擎之間的差異。

連接管理與安全性

每個(gè)客戶(hù)端連接都會(huì)在服務(wù)器進(jìn)程中擁有一個(gè)線(xiàn)程，這個(gè)連接的查詢(xún)只會(huì)在這個(gè)單獨(dú)的線(xiàn)程中執(zhí)行。

服務(wù)器會(huì)緩存線(xiàn)程或者使用線(xiàn)程池技術(shù)，不需要為每個(gè)連接創(chuàng)建一個(gè)線(xiàn)程，因而使用較少的線(xiàn)程來(lái)服務(wù)大量的連接。

當(dāng)客戶(hù)連接服務(wù)器的時(shí)候，服務(wù)器會(huì)對(duì)其進(jìn)行認(rèn)證，基于用戶(hù)名、密碼、主機(jī)信息。

客戶(hù)連接上服務(wù)器，執(zhí)行某個(gè)操作時(shí)，服務(wù)器會(huì)對(duì)其進(jìn)行權(quán)限判斷，判斷該用戶(hù)是否有權(quán)限進(jìn)行該項(xiàng)操作。

優(yōu)化與執(zhí)行

MySQL會(huì)解析查詢(xún),并創(chuàng)建解析樹(shù)，然后對(duì)其進(jìn)行各種優(yōu)化，包括重寫(xiě)查詢(xún)、決定表的讀取順序，以及選取合適的索引等。

用戶(hù)可以使用特殊的關(guān)鍵字提示(hint)優(yōu)化器，影響其決策過(guò)程。

也可以請(qǐng)求優(yōu)化器解釋(explain)優(yōu)化過(guò)程，讓客戶(hù)知道服務(wù)器如何進(jìn)行優(yōu)化。

以便用戶(hù)修改查詢(xún)和schema、修改相關(guān)配置，使之高效運(yùn)行。

優(yōu)化器并不關(guān)心表使用的是什么存儲(chǔ)引擎，但存儲(chǔ)引擎對(duì)于優(yōu)化查詢(xún)是有影響的。

對(duì)于SELECT語(yǔ)句，在解析查詢(xún)之前，服務(wù)器會(huì)先檢查查詢(xún)緩存(Query Cache),如果能找到對(duì)應(yīng)的查詢(xún)，服務(wù)器就會(huì)直接返回查詢(xún)緩存中的結(jié)果集。

并發(fā)控制

無(wú)論何時(shí)，只要有多個(gè)查詢(xún)需要在同一時(shí)刻修改數(shù)據(jù)，就會(huì)產(chǎn)生并發(fā)控制問(wèn)題。

MySQL的并發(fā)控制包含兩個(gè)層面： 服務(wù)器層和存儲(chǔ)引擎層

MySQL的并發(fā)控制主要靠鎖機(jī)制解決。

讀寫(xiě)鎖

讀鎖(read lock) 也叫 共享鎖(shared lock)

寫(xiě)鎖(write lock) 也叫 排他鎖(exclusive lock)

讀鎖是共享的，是相互不阻塞的。多個(gè)客戶(hù)可以同時(shí)讀取同一個(gè)資源而不受干擾。

寫(xiě)鎖是排他的，一個(gè)寫(xiě)鎖會(huì)阻塞其他的讀鎖和寫(xiě)鎖。

在實(shí)際的數(shù)據(jù)庫(kù)系統(tǒng)中，每時(shí)每刻都會(huì)發(fā)生鎖定。大多數(shù)時(shí)候，MySQL鎖的內(nèi)部管理都是透明的。

鎖粒度

加鎖會(huì)消耗資源。鎖的各種操作，包括獲得鎖，檢查所是否解除，釋放鎖，都會(huì)增加系統(tǒng)開(kāi)銷(xiāo)。

鎖的粒度越小，就能對(duì)修改的數(shù)據(jù)片進(jìn)行更精確的鎖定，系統(tǒng)的并發(fā)程度就越高，但是系統(tǒng)的開(kāi)銷(xiāo)就越大。

表鎖(table lock)

表鎖是MySQL中最基本的一種鎖策略，并且是開(kāi)銷(xiāo)最小的策略,它會(huì)鎖定整張表。

當(dāng)一個(gè)用戶(hù)在對(duì)表進(jìn)行寫(xiě)操作(插入、刪除、更新等)前，需要先獲取寫(xiě)鎖，這會(huì)阻塞其他用戶(hù)對(duì)該表的所有讀寫(xiě)操作。

只有在沒(méi)有寫(xiě)鎖時(shí)，其他用戶(hù)才能獲得讀鎖。

盡管存儲(chǔ)引擎可以管理自己的鎖，MySQL本身還是會(huì)使用各種有效的表鎖來(lái)實(shí)現(xiàn)不同的目的。

比如，服務(wù)器會(huì)為諸如ALTER TABLE之類(lèi)的語(yǔ)句使用表鎖，而忽略存儲(chǔ)引擎的鎖機(jī)制。

行級(jí)鎖(row lock)

行級(jí)鎖可以最大程度的支持并發(fā)操作(同時(shí)也帶來(lái)了最大的鎖開(kāi)銷(xiāo))

行級(jí)鎖只在存儲(chǔ)引擎層次實(shí)現(xiàn)，而在MySQL服務(wù)器層沒(méi)有實(shí)現(xiàn)，服務(wù)器層完全不了解存儲(chǔ)引擎中的鎖實(shí)現(xiàn)。

所有存儲(chǔ)引擎都以自己的方式實(shí)現(xiàn)了鎖機(jī)制。

事務(wù)

事務(wù)就是一組原子性的SQL查詢(xún)，或者說(shuō)一個(gè)獨(dú)立的工作單元。

事務(wù)內(nèi)的語(yǔ)句，要么全部成功，要么全部失敗。

事務(wù)的ACID特性，表示原子性(atomicity)、一致性(consistency)、隔離性(isolation)、永久性(durability)

用戶(hù)可以根據(jù)業(yè)務(wù)是否需要事務(wù)處理，來(lái)選擇合適的存儲(chǔ)引擎。

對(duì)于不需要事務(wù)的查詢(xún)類(lèi)應(yīng)用，可以選擇一個(gè)非事務(wù)型的存儲(chǔ)引擎。

隔離級(jí)別

在SQL標(biāo)準(zhǔn)中定義了4種隔離級(jí)別，每一種級(jí)別都規(guī)定了一個(gè)事務(wù)中所做的修改，哪些在事務(wù)內(nèi)和事務(wù)間是可見(jiàn)的，哪些是不可見(jiàn)的。

較低級(jí)別的隔離通常可以執(zhí)行更高的并發(fā)，系統(tǒng)的開(kāi)銷(xiāo)也更低。

READ UNCOMMITTED (未提交讀)

在這個(gè)級(jí)別，事務(wù)中的修改，即便沒(méi)有提交，對(duì)其他事務(wù)也是可見(jiàn)的。事務(wù)可以讀取未提交的數(shù)據(jù)，這也被成為臟讀（Dirty Read）

這個(gè)級(jí)別會(huì)導(dǎo)致很多問(wèn)題，性能也不會(huì)比別的級(jí)別好很多，也沒(méi)有別的級(jí)別的優(yōu)點(diǎn)，實(shí)際應(yīng)用中很少使用。

READ COMMITTED (提交讀)

大多數(shù)數(shù)據(jù)庫(kù)系統(tǒng)的默認(rèn)隔離級(jí)別都是這個(gè)（mysql不是)。

在這個(gè)級(jí)別，一個(gè)事務(wù)開(kāi)始時(shí)，只能‘看到’已經(jīng)提交的事務(wù)所作的修改。即：一個(gè)事務(wù)從開(kāi)始知道提交之前，所作的修改對(duì)其他事務(wù)都是不可見(jiàn)的。

場(chǎng)景：

在一個(gè)事務(wù)內(nèi)，多次讀同一個(gè)數(shù)據(jù)。在這個(gè)事務(wù)還沒(méi)有結(jié)束時(shí)，另一個(gè)事務(wù)也訪(fǎng)問(wèn)該同一數(shù)據(jù)。
那么，在第一個(gè)事務(wù)的兩次讀數(shù)據(jù)之間。
由于第二個(gè)事務(wù)的修改，那么第一個(gè)事務(wù)讀到的數(shù)據(jù)可能不一樣。
這樣就發(fā)生了在一個(gè)事務(wù)內(nèi)兩次讀到的數(shù)據(jù)是不一樣的。

因而這個(gè)級(jí)別有時(shí)候也叫做不可重復(fù)讀

REPEATABLE READ (可重復(fù)讀)

這個(gè)級(jí)別是MySQL默認(rèn)的事務(wù)隔離級(jí)別

這個(gè)級(jí)別解決了臟讀的問(wèn)題，保證在同一個(gè)事務(wù)中的多次讀取同樣記錄的結(jié)果是一致的，但是該級(jí)別無(wú)法解決幻讀(Phantom Read)的問(wèn)題

所謂幻讀：就是當(dāng)一個(gè)事務(wù)在讀取某個(gè)范圍的記錄時(shí)，另一個(gè)事務(wù)又在該范圍插入了新的記錄，之前的事務(wù)再次讀取該范圍的數(shù)據(jù)時(shí)，會(huì)產(chǎn)生幻行(Phantom Row)

SERIALIZABLE (可串行化)

這個(gè)級(jí)別是最高的隔離級(jí)別，它通過(guò)強(qiáng)制事務(wù)串行執(zhí)行，避免了前面的幻讀的的問(wèn)題。

其他的隔離級(jí)別中，各個(gè)事務(wù)還是有一定程度的并發(fā)執(zhí)行。

可串行化會(huì)在讀取的每一行數(shù)據(jù)上都加鎖，可能會(huì)導(dǎo)致大量的超時(shí)和鎖爭(zhēng)用的問(wèn)題，實(shí)際中很少使用。

死鎖

死鎖是指兩個(gè)或者多個(gè)事務(wù)在同一資源上相互占用，并請(qǐng)求鎖定對(duì)方占用的資源，從而導(dǎo)致惡性循環(huán)的現(xiàn)象。

當(dāng)多個(gè)事務(wù)試圖以不同的順序鎖定資源時(shí)，就可能產(chǎn)生死鎖。

多個(gè)事務(wù)同時(shí)鎖定同一個(gè)資源時(shí)，也會(huì)產(chǎn)生死鎖。

例如下面兩個(gè)事務(wù)同時(shí)處理 StockPrice表：

事務(wù)1

    START TRANSACTION;
    UPDATE StockPrice SET close = 45.50 WHERE stock_id = 4;
    UPDATE StockPrice SET close = 19.80 WHERE stock_id = 5;
    COMMIT;

事務(wù)2

    START TRANSACTION;
    UPDATE StockPrice SET close = 19.80 WHERE stock_id = 5;
    UPDATE StockPrice SET close = 45.50 WHERE stock_id = 4;
    COMMIT;

如果剛好兩個(gè)事務(wù)都執(zhí)行了第一條UPDATE語(yǔ)句，更新了一條數(shù)據(jù)，同時(shí)也鎖定了該行數(shù)據(jù)。

然后每個(gè)事務(wù)都嘗試去執(zhí)行第二條UPDATE語(yǔ)句，發(fā)現(xiàn)已經(jīng)被對(duì)方鎖定，然后都等待對(duì)方釋放鎖，又都同時(shí)持有對(duì)方需要的鎖，則陷入死循環(huán)。除非有外部接入才可能解除死鎖。

為了解決這個(gè)問(wèn)題，數(shù)據(jù)庫(kù)系統(tǒng)實(shí)現(xiàn)了各種死鎖檢測(cè)和死鎖超時(shí)機(jī)制。

死鎖發(fā)生后，只有部分或者完全回滾其中一個(gè)事務(wù)，才能打破死鎖。

InnoDB處理死鎖的辦法是：將持有最少行級(jí)排他鎖的事務(wù)進(jìn)行回滾。

事務(wù)日志

使用事務(wù)日志，存儲(chǔ)引擎在修改表的數(shù)據(jù)時(shí)只需要修改其內(nèi)存拷貝，再把該修改行為記錄到持久在硬盤(pán)的事務(wù)日志中，不用每次都把修改的數(shù)據(jù)持久到磁盤(pán)。

事務(wù)采用追加的方式，因此寫(xiě)日志是對(duì)磁盤(pán)上一小塊位置的順序IO，速度較快。

事務(wù)日志持久化之后，內(nèi)存中被修改的數(shù)據(jù)在后臺(tái)可以慢慢的刷回到磁盤(pán)。如果系統(tǒng)崩潰，存儲(chǔ)引擎在重啟時(shí)可以根據(jù)事務(wù)日志恢復(fù)數(shù)據(jù)。

這種稱(chēng)之為預(yù)寫(xiě)式日志(Write-Ahead Logging),修改數(shù)據(jù)需要寫(xiě)兩次磁盤(pán)。

MySQL中的事務(wù)

MySQL提供了兩種事務(wù)型的存儲(chǔ)引擎：InnoDB 和 NDB Cluster。

自動(dòng)提交 (AUTOCOMMIT)

MySQL默認(rèn)采用自動(dòng)提交模式。也就是說(shuō)，如果不是顯示的開(kāi)始一個(gè)事務(wù)，則每個(gè)查詢(xún)都被當(dāng)做一個(gè)事務(wù)執(zhí)行操作。

在當(dāng)前連接中，可以通過(guò)設(shè)置 AUTOCOMMIT 變量來(lái)啟用或者禁用自動(dòng)提交模式。

    SHOW VARIABLES LIKE 'AUTOCOMMIT';

對(duì)于非事務(wù)型的表，相當(dāng)于一直處于AUTOCOMMIT的狀態(tài)。

MySQL可以通過(guò)執(zhí)行 SET TRANSACTION ISOLATION LEVEL XXX 命令來(lái)設(shè)置隔離級(jí)別，新的隔離級(jí)別會(huì)在下一個(gè)事務(wù)開(kāi)始時(shí)生效。

可以在配置文件中設(shè)置整個(gè)數(shù)據(jù)庫(kù)的隔離級(jí)別，也可以只改變當(dāng)前會(huì)話(huà)的隔離級(jí)別：

    SET SESSION TRANSACTION ISOLATION LEVEL READ COMMIT 

在事務(wù)中混合使用存儲(chǔ)引擎

MySQL服務(wù)器層不管理事務(wù)，事務(wù)是由下層的存儲(chǔ)引擎實(shí)現(xiàn)的。所以在同一個(gè)事務(wù)中使用多種存儲(chǔ)引擎是不可靠的。

如果在事務(wù)中混合使用了事務(wù)型和非事務(wù)型存儲(chǔ)引擎，在正常提交的情況下不會(huì)有什么問(wèn)題。

但是如果該事務(wù)需要回滾，非事務(wù)型的表上的變更無(wú)法撤銷(xiāo)。

在非事務(wù)型的表上執(zhí)行事務(wù)相關(guān)操作的時(shí)候，MySQL通常不會(huì)發(fā)出提醒，也不會(huì)報(bào)錯(cuò)，只有在回滾的時(shí)候才會(huì)發(fā)一個(gè)警告：‘某些非事務(wù)型的表上的變更無(wú)法被回滾’。

隱式和顯示鎖定

InnoDB會(huì)根據(jù)隔離級(jí)別在需要的時(shí)候自動(dòng)加鎖，這種鎖定叫做隱式鎖定。

另外，InnoDB也支持通過(guò)特定的語(yǔ)句進(jìn)行顯示鎖定，這些語(yǔ)句不屬于SQL規(guī)范。

    SELECT ... LOCK IN SHARE MODE
    SELECT ... FOR UPDATE

MySQL也支持 LOCK TABLES 和 UNLOCK TABLES 語(yǔ)句，這是在服務(wù)器層實(shí)現(xiàn)的，與存儲(chǔ)引擎無(wú)關(guān)，不能替代事務(wù)處理。

但是建議任何時(shí)候都不要顯示的執(zhí)行 LOCK TABLES。

多版本并發(fā)控制

MySQL的大多數(shù)事務(wù)型存儲(chǔ)引擎實(shí)現(xiàn)的都不是簡(jiǎn)單的行級(jí)鎖。基于提升并發(fā)性能的考慮，一般都實(shí)現(xiàn)了 多版本并發(fā)控制（MVCC）。

不僅是MySQL,包括Oracle、PostgreSQL等其他數(shù)據(jù)庫(kù)系統(tǒng)都實(shí)現(xiàn)了MVCC,但實(shí)現(xiàn)的機(jī)制不盡相同，因?yàn)镸VCC沒(méi)有統(tǒng)一的實(shí)現(xiàn)標(biāo)準(zhǔn)。

MVCC可以認(rèn)為是行級(jí)鎖的一個(gè)變種，在很多情況下避免了加鎖操作，因此開(kāi)銷(xiāo)更低。

雖然實(shí)現(xiàn)機(jī)制不同，但大都實(shí)現(xiàn)了非阻塞的讀操作，寫(xiě)操作也只鎖定必要的行。

Mysql的存儲(chǔ)引擎

InnoDB 存儲(chǔ)引擎

InnoDB存儲(chǔ)引擎是MySQL自5.5版本以來(lái)的默認(rèn)事務(wù)型引擎，也是最重要、使用最廣泛的存儲(chǔ)引擎。

它被設(shè)計(jì)用來(lái)處理大量的短期事務(wù)，在非事務(wù)行的存儲(chǔ)的需求中也很流行。

除非有非常特別的原因需要使用其他的存儲(chǔ)引擎，否則應(yīng)該優(yōu)先考慮使用InnoDB引擎。

MyISAM 存儲(chǔ)引擎

在MySQL5.1及之前的版本，MyISAM是默認(rèn)的存儲(chǔ)引擎，MyISAM不支持事務(wù)和行級(jí)鎖。

其他存儲(chǔ)引擎

Archive引擎

Archive存儲(chǔ)引擎只支持INSERT和SELECT操作

Backhole引擎

Backhole沒(méi)有實(shí)現(xiàn)任何的存儲(chǔ)機(jī)制，他會(huì)丟棄所有插入的數(shù)據(jù)，不做保存，服務(wù)器會(huì)記錄Backhole表的日志。

CSV引擎

CSV引擎可以將普通的csv文件作為MySQL的表來(lái)處理，但是這種引表不支持索引。

Memory引擎

Memory引擎數(shù)據(jù)保存在內(nèi)存中，查詢(xún)速度快，但是重啟之后數(shù)據(jù)丟失，表結(jié)構(gòu)還會(huì)保留。

NDB集群引擎

MySQL服務(wù)器，NDB集群存儲(chǔ)引擎，以及分布式的、share-nothing的、容災(zāi)的、高可用的NDB數(shù)據(jù)庫(kù)的組合，被稱(chēng)為MySQL集群(MySQL Cluster)。

第三方存儲(chǔ)引擎

MySQL從2007年開(kāi)始提供插件式的存儲(chǔ)引擎API,從此產(chǎn)生了許多為不同目的而設(shè)計(jì)的存儲(chǔ)引擎

主要有： OLTP類(lèi)引擎、 面向列的存儲(chǔ)引擎、社區(qū)存儲(chǔ)引擎 等。

選擇合適的存儲(chǔ)引擎

大多數(shù)情況下，InnoDB都是正確的選擇。

只有遇到一些比較特殊的需求時(shí)，才會(huì)考慮用其他引擎。

Mysql時(shí)間線(xiàn)

1995 MySQL AB公司創(chuàng)建。

2008年 MySQL AB公司被SUN收購(gòu)

2010年 SUN公司被Oracle收購(gòu)

隨著MySQL被Oracle收購(gòu)，許多公司開(kāi)始尋找替代品。

倒向MariaDB: 谷歌(2013年9月) RedHat(2013年6月) 維基百科(2013年4月)

倒向PostreSQL: 蘋(píng)果(2011年)