一、MySQL邏輯架構(gòu)

　　第一層的服務(wù)不是MySQL獨(dú)有的，大多數(shù)是基于網(wǎng)絡(luò)的客戶端/服務(wù)端的工具，如連接處理、授權(quán)認(rèn)證、安全等等。

　　第二層就是MySQL的核心功能，包括查詢解析、分析、優(yōu)化、緩存以及所有的內(nèi)置函數(shù)，所有的跨存儲引擎的功能都在這一層實(shí)現(xiàn)：存儲過程、觸發(fā)器、視圖等。

　　第三層包含了存儲引擎，主要負(fù)責(zé)MySQL中數(shù)據(jù)的存儲和提取。

1.連接管理與安全

　　每個客戶端連接都會服務(wù)器進(jìn)程中擁有一個線程，這個連接的查詢只會在這個單獨(dú)的線程中執(zhí)行，該線程只能輪流在某個CPU核心或者CPU中運(yùn)行，服務(wù)器會緩存線程，所以不需要對每個連接新建或者銷毀一個線程（可以復(fù)用緩存中的線程）。

　　當(dāng)客戶端連接到MySQL時服務(wù)器需要對其進(jìn)行認(rèn)證，如果認(rèn)證成功，服務(wù)器會繼續(xù)驗(yàn)證該客戶是否有執(zhí)行某個待定查詢的權(quán)限。

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

　　MySQL會解析查詢，并且創(chuàng)建內(nèi)部數(shù)據(jù)結(jié)構(gòu)（解析樹），然后對其進(jìn)行各種優(yōu)化，包括重寫查詢SQL、決定表的讀取順序，以及選擇合適的索引等。

　　對于一個SELECT查詢語句來說：在解析查詢之前，服務(wù)器會先檢查查詢緩存，如果能夠在其中找到對應(yīng)的查詢，服務(wù)器會直接返回結(jié)果，不需要再執(zhí)行查詢解析、優(yōu)化和執(zhí)行整個過程。

二、并發(fā)控制

1.讀寫鎖

　　比如有一張表，多個線程對這張表進(jìn)行操作，加入剛好有一個線程在對一條數(shù)據(jù)更改，另一個線程也對其進(jìn)行讀取操作，那么進(jìn)行讀操作的這個線程可能讀到的數(shù)據(jù)是不正確的，怎么解決這個問題呢？這時就用到了并發(fā)控制，主要是通過兩種鎖來控制的：讀鎖（共享鎖）、寫鎖（排他鎖）

　　讀鎖是共享的，或者說是相互不阻塞的，即對個線程讀取同一個資源，互不干擾；寫鎖是排他的，也就是說只要有一個線程對其進(jìn)行寫操作，那么其他的讀和寫線程將都會被阻塞。只有這樣才能保證才能保證在給定的時間內(nèi)只有一個線程在寫操作，并防止其他線程讀取正在寫入的數(shù)據(jù)。

2.鎖粒度

　　最理想的情況是：需要寫入哪個對象就鎖定哪個對象。盡量只鎖定需要修改的部分?jǐn)?shù)據(jù)，而不是所有的數(shù)據(jù)。在任何時候，在給定的資源上，鎖定的數(shù)據(jù)越少，系統(tǒng)的并發(fā)程度越高。

　　但是還有一個問題，加鎖也會消耗資源，鎖的各種操作：獲得鎖、檢查鎖是否已經(jīng)解除、釋放鎖等，都會增加系統(tǒng)的開銷，如果花費(fèi)大量的時間來管理鎖，而不是存取數(shù)據(jù)，那么系統(tǒng)的性能將會受到影響。

　　所謂的鎖策略，就是在鎖的開銷和數(shù)據(jù)的完全性之間尋求平衡。

　　表鎖是MySQL中最基本的鎖策略，并且是開銷最小的策略（意味著并發(fā)程度低），但是表鎖的缺點(diǎn)是在執(zhí)行插入、刪除、更改的操作時會使其他的用戶線程阻塞。（注意：讀鎖之間是互不影響的）。另外寫鎖比讀鎖的優(yōu)先級更高。寫鎖可以插到讀鎖中，但是讀鎖卻不能插到寫鎖中。

　　行級鎖：可以最大程度的支持并發(fā)處理（但是同時也帶來了更大的鎖開銷）最典型的就是InnoDB存儲引擎，行級鎖只在存儲引擎層實(shí)現(xiàn)。

三、事務(wù)

　　最重要的事務(wù)終于到啦，事務(wù)即ACID（原子性、一致性、隔離性、持久性），在開始講這四個特性之前我們先舉一個最經(jīng)典的例子：某賬戶存了1000元，現(xiàn)在用戶A要往里面存200元、用戶B要往出來取200元。

　　原子性：一個事務(wù)必須被視為不可分割的最小工作單元，整個事務(wù)的所有操作要么全部提交完成，要么全部失敗回滾，對于一個事務(wù)來說不可能執(zhí)行其中的一部分。那上面例子來說：A要從賬戶取200需要執(zhí)行以下四步操作：

1 START TRANSACTION;
2 SELECT  '金額'  FROM  '賬戶表'  WHERE   user_id = 1221221;
3 UPDATE  '賬戶表'  SET  '金額'  =  '金額'  - 200  WHERE user_id = 1221221;
4 COMMIT;

　　解釋：1.開啟事務(wù) ，2.查詢賬戶有沒有200元 ，3.扣除金額  ， 4.提交事務(wù)。

　　原子性就是指這四步完整執(zhí)行不可再分。

　　一致性：數(shù)據(jù)庫從一個一致性的狀態(tài)轉(zhuǎn)換為另一個一致性的狀態(tài)。就上面那個例子：如果在第三步執(zhí)行完系統(tǒng)崩潰，賬戶中的金額還是1000元，因?yàn)橐粋€事務(wù)沒有執(zhí)行完，在最終提交前是不會保存到數(shù)據(jù)庫中的。

　　隔離性：通常來講一個事務(wù)在最終提交前，對其他事務(wù)是不可見的。就之前例子來說，第三步執(zhí)行完，在沒提交之前B賬戶來看到的金額仍然是1000元。是不可見的。

　　持久性：事務(wù)一旦提交其所做的修改就會永遠(yuǎn)的被保存到數(shù)據(jù)庫中，即使系統(tǒng)崩潰也不會丟失。

　　一個實(shí)現(xiàn)了事務(wù)的數(shù)據(jù)庫相比于沒有實(shí)現(xiàn)事務(wù)的數(shù)據(jù)庫它需要更強(qiáng)的CPU處理能力、更大的內(nèi)存、更多的磁盤空間。對于有些不需要事務(wù)的查詢類應(yīng)用選擇一個非事務(wù)型的存儲引擎可以獲得更高的性能。

1.隔離級別

一共有四種隔離級別先簡單做個介紹：

A.READ  UNCOMMIT（讀未提交）

　　在這個隔離級別中，事務(wù)的修改，即使沒有提交，對其他的事務(wù)也是可見的。事務(wù)可以讀到未提交的數(shù)據(jù)，這些數(shù)據(jù)也被稱為臟讀。

B.READ  COMMIT（讀已提交）（不可重復(fù)讀）

　　大多數(shù)數(shù)據(jù)庫系統(tǒng)的默認(rèn)隔離級別都是讀已提交，但是MySQL不是，MySQL的默認(rèn)隔離級別是可重復(fù)讀。簡單說就是一個事務(wù)開始時只能 “看見” 已經(jīng)提交的事務(wù)所做的修改，換句話說，一個事務(wù)從開始到提交這個過程中所做的所有修改對其他事務(wù)是不可見的。這個級別對于兩次執(zhí)行相同情況的查詢，可能會得到不同的結(jié)果。

C.REPEATABLE  READ（可重復(fù)讀）

　　該級別保證了在同一個事務(wù)中多次讀取同樣的記錄結(jié)果是一致的，但是它無法解決幻讀的問題。

D.SERIALIZABLE（可串行化）

　　是最高的隔離級別。它通過強(qiáng)制事務(wù)串行化執(zhí)行，避免了所有問題，他會在讀取的每一行記錄上面都加鎖，所以可能導(dǎo)致大量的超時與鎖等待的問題，并發(fā)低。

講幾個概念：

1.臟讀：A用戶把錢取出沒有提交，B用戶讀取到修改了的金額為800，過一會A因?yàn)楫惓Ｊ聞?wù)回滾，B再次讀取發(fā)現(xiàn)值變?yōu)?000，兩次不一樣，第一次讀到的是臟數(shù)據(jù)。

2.不可以重復(fù)讀：B讀到數(shù)據(jù)為1000后，A修改數(shù)據(jù)為800并且提交，B再次讀取為800，兩次數(shù)據(jù)不一致。

3.幻讀：與不可重復(fù)讀類似：B讀到一個表里有10條記錄，A插了一條并提交，B再次讀為11條，感覺發(fā)生幻覺一樣。

不同隔離級別引發(fā)的問題：

 2.死鎖

多個事務(wù)在同一資源上相互占有，并且請求鎖定對方占用的資源，從而導(dǎo)致惡性循環(huán)的現(xiàn)象。

數(shù)據(jù)庫系統(tǒng)實(shí)現(xiàn)了各種死鎖檢測和死鎖超時機(jī)制。InnoDB目前處理死鎖的方法是：將持有最少行排它鎖的事務(wù)進(jìn)行回滾。

3.事務(wù)日志

事務(wù)日志可以提高事務(wù)的效率，使用事務(wù)日志時：存儲引擎在修改表數(shù)據(jù)時只需要修改其內(nèi)存拷貝，再把該修改行為記錄到持久在硬盤上的事務(wù)日志中，不用每次將修改的數(shù)據(jù)本身持久到硬盤。事務(wù)日志采用追加的方式，寫日志的操作是磁盤上的一小塊區(qū)域內(nèi)的順序I/O.事務(wù)日志持久后，內(nèi)存中被修改的數(shù)據(jù)將在后臺慢慢刷回到磁盤。所以一共需要兩次磁盤I/O:一次寫日志磁盤I/O,一次刷回磁盤I/O.

4.MySQL中的事務(wù)

1.自動提交：MySQL默認(rèn)采用自動提交的方式。比如每個查詢就是一個事務(wù)執(zhí)行完自動提交。

2.非事務(wù)型存儲引擎如：MyISAM無回滾功能。

四、多版本并發(fā)控制MVCC

　　可以認(rèn)為MVCC是行級鎖的一個變種，它在很多情況下避免了加鎖，MVCC的實(shí)現(xiàn)是通過保存數(shù)據(jù)在某個時間的快照來實(shí)現(xiàn)的。

　　InnoDB的MVCC，是通過在每行記錄后面保存兩個隱藏的列來實(shí)現(xiàn)的，這兩個列一個保存了行的創(chuàng)建時間，一個保存了行的刪除時間，存儲的不是真正時間而是系統(tǒng)的版本號。每個新事物開始系統(tǒng)版本號自動遞增。事物開始時刻的版本號作為事物的版本號，用來和查詢到的每行記錄版本號進(jìn)行比較。

　　MVCC只在可重復(fù)讀和讀已提交兩個隔離級別下工作，其他兩個級別都和MVCC不兼容。因?yàn)樽x未提交總是讀取最新的數(shù)據(jù)行，不符合當(dāng)前事物版本的數(shù)據(jù)行?？纱谢瘯λ行屑渔i。

　　我的理解其實(shí)MVCC就跟CAS是一個原理，就是一個比較并交換的過程。