第一層的服務不是MySQL獨有的，大多數(shù)是基于網(wǎng)絡的客戶端/服務端的工具，如連接處理、授權認證、安全等等。
第二層就是MySQL的核心功能，包括查詢解析、分析、優(yōu)化、緩存以及所有的內(nèi)置函數(shù)，所有的跨存儲引擎的功能都在這一層實現(xiàn)：存儲過程、觸發(fā)器、視圖等。
第三層包含了存儲引擎，主要負責MySQL中數(shù)據(jù)的存儲和提取。
每個客戶端連接都會服務器進程中擁有一個線程，這個連接的查詢只會在這個單獨的線程中執(zhí)行，該線程只能輪流在某個CPU核心或者CPU中運行，服務器會緩存線程，所以不需要對每個連接新建或者銷毀一個線程（可以復用緩存中的線程）。
當客戶端連接到MySQL時服務器需要對其進行認證，如果認證成功，服務器會繼續(xù)驗證該客戶是否有執(zhí)行某個待定查詢的權限。
MySQL會解析查詢，并且創(chuàng)建內(nèi)部數(shù)據(jù)結構（解析樹），然后對其進行各種優(yōu)化，包括重寫查詢SQL、決定表的讀取順序，以及選擇合適的索引等。
對于一個SELECT查詢語句來說：在解析查詢之前，服務器會先檢查查詢緩存，如果能夠在其中找到對應的查詢，服務器會直接返回結果，不需要再執(zhí)行查詢解析、優(yōu)化和執(zhí)行整個過程。
比如有一張表，多個線程對這張表進行操作，加入剛好有一個線程在對一條數(shù)據(jù)更改，另一個線程也對其進行讀取操作，那么進行讀操作的這個線程可能讀到的數(shù)據(jù)是不正確的，怎么解決這個問題呢？這時就用到了并發(fā)控制，主要是通過兩種鎖來控制的：讀鎖（共享鎖）、寫鎖（排他鎖）
讀鎖是共享的，或者說是相互不阻塞的，即對個線程讀取同一個資源，互不干擾；寫鎖是排他的，也就是說只要有一個線程對其進行寫操作，那么其他的讀和寫線程將都會被阻塞。只有這樣才能保證才能保證在給定的時間內(nèi)只有一個線程在寫操作，并防止其他線程讀取正在寫入的數(shù)據(jù)。
最理想的情況是：需要寫入哪個對象就鎖定哪個對象。盡量只鎖定需要修改的部分數(shù)據(jù)，而不是所有的數(shù)據(jù)。在任何時候，在給定的資源上，鎖定的數(shù)據(jù)越少，系統(tǒng)的并發(fā)程度越高。
但是還有一個問題，加鎖也會消耗資源，鎖的各種操作：獲得鎖、檢查鎖是否已經(jīng)解除、釋放鎖等，都會增加系統(tǒng)的開銷，如果花費大量的時間來管理鎖，而不是存取數(shù)據(jù)，那么系統(tǒng)的性能將會受到影響。
所謂的鎖策略，就是在鎖的開銷和數(shù)據(jù)的完全性之間尋求平衡。
表鎖是MySQL中最基本的鎖策略，并且是開銷最小的策略（意味著并發(fā)程度低），但是表鎖的缺點是在執(zhí)行插入、刪除、更改的操作時會使其他的用戶線程阻塞。（注意：讀鎖之間是互不影響的）。另外寫鎖比讀鎖的優(yōu)先級更高。寫鎖可以插到讀鎖中，但是讀鎖卻不能插到寫鎖中。
行級鎖：可以最大程度的支持并發(fā)處理（但是同時也帶來了更大的鎖開銷）最典型的就是InnoDB存儲引擎，行級鎖只在存儲引擎層實現(xiàn)。
最重要的事務終于到啦，事務即ACID（原子性、一致性、隔離性、持久性），在開始講這四個特性之前我們先舉一個最經(jīng)典的例子：某賬戶存了1000元，現(xiàn)在用戶A要往里面存200元、用戶B要往出來取200元。
原子性：一個事務必須被視為不可分割的最小工作單元，整個事務的所有操作要么全部提交完成，要么全部失敗回滾，對于一個事務來說不可能執(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.開啟事務 ，2.查詢賬戶有沒有200元 ，3.扣除金額 ， 4.提交事務。
原子性就是指這四步完整執(zhí)行不可再分。
一致性：數(shù)據(jù)庫從一個一致性的狀態(tài)轉換為另一個一致性的狀態(tài)。就上面那個例子：如果在第三步執(zhí)行完系統(tǒng)崩潰，賬戶中的金額還是1000元，因為一個事務沒有執(zhí)行完，在最終提交前是不會保存到數(shù)據(jù)庫中的。
隔離性：通常來講一個事務在最終提交前，對其他事務是不可見的。就之前例子來說，第三步執(zhí)行完，在沒提交之前B賬戶來看到的金額仍然是1000元。是不可見的。
持久性：事務一旦提交其所做的修改就會永遠的被保存到數(shù)據(jù)庫中，即使系統(tǒng)崩潰也不會丟失。
一個實現(xiàn)了事務的數(shù)據(jù)庫相比于沒有實現(xiàn)事務的數(shù)據(jù)庫它需要更強的CPU處理能力、更大的內(nèi)存、更多的磁盤空間。對于有些不需要事務的查詢類應用選擇一個非事務型的存儲引擎可以獲得更高的性能。
一共有四種隔離級別先簡單做個介紹：
A.READ UNCOMMIT（讀未提交）
在這個隔離級別中，事務的修改，即使沒有提交，對其他的事務也是可見的。事務可以讀到未提交的數(shù)據(jù)，這些數(shù)據(jù)也被稱為臟讀。
B.READ COMMIT（讀已提交）（不可重復讀）
大多數(shù)數(shù)據(jù)庫系統(tǒng)的默認隔離級別都是讀已提交，但是MySQL不是，MySQL的默認隔離級別是可重復讀。簡單說就是一個事務開始時只能 “看見” 已經(jīng)提交的事務所做的修改，換句話說，一個事務從開始到提交這個過程中所做的所有修改對其他事務是不可見的。這個級別對于兩次執(zhí)行相同情況的查詢，可能會得到不同的結果。
C.REPEATABLE READ（可重復讀）
該級別保證了在同一個事務中多次讀取同樣的記錄結果是一致的，但是它無法解決幻讀的問題。
D.SERIALIZABLE（可串行化）
是最高的隔離級別。它通過強制事務串行化執(zhí)行，避免了所有問題，他會在讀取的每一行記錄上面都加鎖，所以可能導致大量的超時與鎖等待的問題，并發(fā)低。
講幾個概念：
1.臟讀：A用戶把錢取出沒有提交，B用戶讀取到修改了的金額為800，過一會A因為異常事務回滾，B再次讀取發(fā)現(xiàn)值變?yōu)?000，兩次不一樣，第一次讀到的是臟數(shù)據(jù)。
2.不可以重復讀：B讀到數(shù)據(jù)為1000后，A修改數(shù)據(jù)為800并且提交，B再次讀取為800，兩次數(shù)據(jù)不一致。
3.幻讀：與不可重復讀類似：B讀到一個表里有10條記錄，A插了一條并提交，B再次讀為11條，感覺發(fā)生幻覺一樣。
不同隔離級別引發(fā)的問題：
多個事務在同一資源上相互占有，并且請求鎖定對方占用的資源，從而導致惡性循環(huán)的現(xiàn)象。
數(shù)據(jù)庫系統(tǒng)實現(xiàn)了各種死鎖檢測和死鎖超時機制。InnoDB目前處理死鎖的方法是：將持有最少行排它鎖的事務進行回滾。
事務日志可以提高事務的效率，使用事務日志時：存儲引擎在修改表數(shù)據(jù)時只需要修改其內(nèi)存拷貝，再把該修改行為記錄到持久在硬盤上的事務日志中，不用每次將修改的數(shù)據(jù)本身持久到硬盤。事務日志采用追加的方式，寫日志的操作是磁盤上的一小塊區(qū)域內(nèi)的順序I/O.事務日志持久后，內(nèi)存中被修改的數(shù)據(jù)將在后臺慢慢刷回到磁盤。所以一共需要兩次磁盤I/O:一次寫日志磁盤I/O,一次刷回磁盤I/O.
1.自動提交：MySQL默認采用自動提交的方式。比如每個查詢就是一個事務執(zhí)行完自動提交。
2.非事務型存儲引擎如：MyISAM無回滾功能。
可以認為MVCC是行級鎖的一個變種，它在很多情況下避免了加鎖，MVCC的實現(xiàn)是通過保存數(shù)據(jù)在某個時間的快照來實現(xiàn)的。
InnoDB的MVCC，是通過在每行記錄后面保存兩個隱藏的列來實現(xiàn)的，這兩個列一個保存了行的創(chuàng)建時間，一個保存了行的刪除時間，存儲的不是真正時間而是系統(tǒng)的版本號。每個新事物開始系統(tǒng)版本號自動遞增。事物開始時刻的版本號作為事物的版本號，用來和查詢到的每行記錄版本號進行比較。
MVCC只在可重復讀和讀已提交兩個隔離級別下工作，其他兩個級別都和MVCC不兼容。因為讀未提交總是讀取最新的數(shù)據(jù)行，不符合當前事物版本的數(shù)據(jù)行。可串行化會對所有行加鎖。
我的理解其實MVCC就跟CAS是一個原理，就是一個比較并交換的過程。
