全面分析 MySQL并發控制

并發控制

為什么會提出這個話題？不言而喻，

無論何時，只要有多個查詢需要在同一時刻查詢資料，都會產生并發問題，
我也不多廢話，如果是進來找代碼實作的，請移步：不是你記憶中的單例模式，但適用的程度，更勝一籌
當然，建議還是打開看一下，說不定就漲了些奇奇怪怪的知識，

本篇雖然題目說：全面分析，但是誰都知道，并發控制是一個多么龐大的概念是吧，本篇主要講的是：MySQL的鎖、存盤引擎、事務處理機制，如果不是你期待的，可以省點時間啦；如果是的話，點贊收藏錯不了！

MySQL邏輯架構

每個連接都會在mysql服務端產生一個執行緒（內部通過執行緒池管理執行緒），比如一個select陳述句進入，mysql首先會在查詢快取中查找是否快取了這個select的結果集，如果沒有則繼續執行 決議、優化、執行的程序；反之則會直接從快取中獲取結果集，

鎖

我們常規認識的鎖是這樣的：對于臨界資源A，有行程B和行程C需要對其進行訪問，為了防止沖突，當某個行程比如說A先到達，它會取得互斥鎖，那么在A使用這個資源的時候，B是無法使用這個資源的，它必須等待，直到A釋放了鎖為止，
在學校里面老師就是在這么教我們的，
當然，并不滿足與此，如果想多了解鎖一點，請移步：面試常問 樂觀鎖、悲觀鎖，互斥鎖、自旋鎖

上面這種互斥鎖的方案在實際應用環境中，但并不支持大并發處理，我們來看看一些解決方案：

讀寫鎖

讀鎖：讀鎖是共享的，多個客戶在同一時刻可以同時讀取同一個資源，而互不干擾（只要你有讀的權限，你就可以當它是透明的），
寫鎖：寫鎖是排他的，也就是說一個寫鎖會阻塞其他的寫鎖和讀鎖，這是出于安全策略的考慮，

具體參見：悲觀鎖和樂觀鎖（資源在上面）

在實際的資料庫系統中，每時每刻都在發生鎖定，大多數時候，MySQL的內部管理都是透明的，

鎖粒度

在這個問題上，我看到了一個非常接地氣的比喻：（出處）

為什么要加鎖？加鎖是為了防止不同的執行緒訪問同一共享資源造成混亂，
打個比方：人是不同的執行緒，衛生間是共享資源
你在上洗手間的時候肯定要把門鎖上吧，這就是加鎖，只要你在里面，這個衛生間就被鎖了，只有你出來之后別人才能用，想象一下如果衛生間的門沒有鎖會是什么樣？

什么是加鎖粒度呢？所謂加鎖粒度就是你要鎖住的范圍是多大，
比如你在家上衛生間，你只要鎖住衛生間就可以了吧，不需要將整個家都鎖起來不讓家人進門吧，衛生間就是你的加鎖粒度，

怎樣才算合理的加鎖粒度呢？
其實衛生間并不只是用來上廁所的，還可以洗澡，洗手，這里就涉及到優化加鎖粒度的問題，
你在衛生間里洗澡，其實別人也可以同時去里面洗手，只要做到隔離起來就可以，如果馬桶，浴缸，洗漱臺都是隔開相對獨立的，實際上衛生間可以同時給三個人使用，
當然三個人做的事兒不能一樣，這樣就細化了加鎖粒度，你在洗澡的時候只要關上浴室的門，別人還是可以進去洗手的，如果當初設計衛生間的時候沒有將不同的功能區域劃分
隔離開，就不能實作衛生間資源的最大化使用，這就是設計架構的重要性，

表鎖（table lock）

表鎖是MySQL中最基本的鎖策略，并且是開銷最小的策略，它會鎖定整張表，這是什么意思我就不多說了啊，
但是吧，放對了位置，表鎖也可以有不錯的體現，比方說服務器會為諸如ALTER TABLE之類的陳述句使用表鎖而忽略存盤引擎的鎖機制，

行級鎖

行級鎖是Mysql中鎖定粒度最細的一種鎖，表示只針對當前操作的行進行加鎖，行級鎖能大大減少資料庫操作的沖突，其加鎖粒度最小，但加鎖的開銷也最大，

InnoDB等比較常用的存盤引擎中都實作了行級鎖，

頁級鎖

頁級鎖是MySQL中鎖定粒度介于行級鎖和表級鎖中間的一種鎖，表級鎖速度快，但沖突多，行級沖突少，但速度慢，所以取了折衷的頁級，一次鎖定相鄰的一組記錄，

事務

MySQL 事務主要用于處理操作量大，復雜度高的資料，比如說，在人員管理系統中，你洗掉一個人員，你既需要洗掉人員的基本資料，也要洗掉和該人員相關的資訊，這樣，這些資料庫操作陳述句就構成一個事務！

在 MySQL 中只有使用了 Innodb 資料庫引擎的資料庫或表才支持事務，
事務處理可以用來維護資料庫的完整性，保證成批的 SQL 陳述句要么全部執行，要么全部不執行，
事務用來管理 insert,update,delete 陳述句

事務的四個特性（ACID）

原子性：一個事務是不可再分割的整體，要么都執行要么都不執行
一致性：一個事務的執行不能破壞資料庫資料的完整性和一致性
隔離性：一個事務不受其它事務的干擾，多個事務是互相隔離的
持久性：一個事務一旦提交了，則永久的持久化到本地

就像鎖粒度的升級會增加系統開銷一樣，這種事務處理程序中額外的安全性也會需要資料庫系統做更多的額外作業，一個實作了ACID的資料庫，相比沒有實作ACID的資料庫，通常會需要更多的CPU處理能力、更大的記憶體和更多的磁盤空間，這也正是MySQL的存盤引擎可以發揮優勢的地方，用戶可以根據自身需要來選定存盤引擎，

隔離級別

資料庫為了壓制丟失更新，提出了4類隔離級別[在application組態檔中宣告]，
資料庫現在的技術完全有辦法避免丟失更新，但是這樣做的代價是要付出鎖的代價，一旦用了過多的鎖，出現商品搶購這類功能的時候，很多執行緒都會被掛起和恢復，因為使用了鎖之后，一個時刻只能有一個執行緒訪問資料，這樣當多個執行緒訪問時，就會很慢，而且過多的鎖會引發宕機，大部分執行緒被掛起，等待持有鎖事務的完成，

隔離性其實比想象的要復雜，我們來看看：
（簡單介紹幾種）

READ UNCOMMITTED（讀取未提交內容）

在該隔離級別，所有事務都可以看到其他未提交事務的執行結果，本隔離級別很少用于實際應用，因為它的性能也不比其他級別好多少，讀取未提交的資料，也被稱之為臟讀（Dirty Read），

Read Committed（讀取提交內容）

這是大多數資料庫系統的默認隔離級別（但不是MySQL默認的），它滿足了隔離的簡單定義：一個事務只能看見已經提交事務所做的改變，這種隔離級別 也支持所謂的不可重復讀（Nonrepeatable Read），因為同一事務的其他實體在該實體處理其間可能會有新的commit，所以同一select可能回傳不同結果，

Repeatable Read（可重讀）

這是MySQL的默認事務隔離級別，它確保同一事務的多個實體在并發讀取資料時，會看到同樣的資料行，不過理論上，這會導致另一個棘手的問題：幻讀 （Phantom Read），簡單的說，幻讀指當用戶讀取某一范圍的資料行時，另一個事務又在該范圍內插入了新行，當用戶再讀取該范圍的資料行時，會發現有新的“幻影” 行，InnoDB和Falcon存盤引擎通過多版本并發控制（MVCC，Multiversion Concurrency Control）機制解決了該問題，

Serializable（可串行化）

這是最高的隔離級別，它通過強制事務排序，使之不可能相互沖突，從而解決幻讀問題，簡言之，它是在每個讀的資料行上加上共享鎖，在這個級別，可能導致大量的超時現象和鎖競爭，

要是再深挖下去，那得是專門的研究員們做的事情了吧，比方說MySQL是如何保證可重復讀的實作，比方說幻讀是怎么被咔嚓掉的之類的，

后面我看看能不能查到些好的資料貼上來，

死鎖

為什么這個死鎖不放在上面“鎖”的模塊里面講呢？木有事務，談什么死鎖，

死鎖的基本概念我也不啰嗦了，為了解決死鎖的問題，資料庫系統實作了各種死鎖檢測和超時機制，InnoDB檢測死鎖的本事就不錯，它會抓出死鎖的回圈依賴，并且拋出一個錯誤，
InnoDB目前處理死鎖的方法：將持有最少行級排他鎖的事務進行回滾，
鎖的行為和存盤引擎是密不可分的，同樣的事務執行順序，有的存盤引擎就會死鎖，有的就不會，，

事務日志

我覺得可以參考一下redis的日志：全面分析redis持久化機制

吃出不過多贅述，其他篇關于MySQL的博客里已經講得夠多了，
如果覺得確實想要了解一下，這里倒是有一篇寫得很全面的：詳細分析MySQL事務日志

想趕緊進入存盤引擎的模塊，

存盤引擎

我先不說話，我先放張圖，你品，你細品

InnoDB

我還是不說話，我放圖：

InnoDB后臺有多個不同的執行緒，用來負責不同的任務，

InnoDB 存盤引擎是基于磁盤存盤的,也就是說資料都是存盤在磁盤上的,由于 CPU 速度和磁盤速度之間的鴻溝, InnoDB 引擎使用緩沖池技術來提高資料庫的整體性能，緩沖池簡單來說就是一塊記憶體區域.在資料庫中進行讀取頁的操作,首先將從磁盤讀到的頁存放在緩沖池中,下一次讀取相同的頁時,首先判斷該頁是不是在緩沖池中,若在,稱該頁在緩沖池中被命中,直接讀取該頁，否則,讀取磁盤上的頁，對于資料庫中頁的修改操作,首先修改在緩沖池中頁,然后再以一定的頻率重繪到磁盤,并不是每次頁發生改變就重繪回磁盤，

在InnoDB中，緩沖池中的頁大小默認為16KB，

InnoDB 給 MySQL 提供了具有事務(transaction)、回滾(rollback)和崩潰修復能力(crash recovery capabilities)、多版本并發控制(multi-versioned concurrency control)的事務安全(transaction-safe (ACID compliant))型表，InnoDB 提供了行級鎖(locking on row level)，提供與 Oracle 類似的不加鎖讀取(non-locking read in SELECTs)，InnoDB鎖定在行級并且也在SELECT陳述句提供一個Oracle風格一致的非鎖定讀，這些特色增加了多用戶部署和性能，沒有在InnoDB中擴大鎖定的需要，因為在InnoDB中行級鎖定適合非常小的空間，InnoDB也支持FOREIGN KEY強制，在SQL查詢中，你可以自由地將InnoDB型別的表與其它MySQL的表的型別混合起來，甚至在同一個查詢中也可以混合，這些特性均提高了多用戶并發操作的性能表現，在InnoDB表中不需要擴大鎖定(lock escalation)，因為 InnoDB 的行級鎖定(row level locks)適宜非常小的空間，InnoDB 是 MySQL 上第一個提供外鍵約束(FOREIGN KEY constraints)的表引擎，

InnoDB采用MVCC來支持高并發，并且實作了四個標準隔離級別，其默認隔離級別是REPEATABLE READ（可重復讀），并且通過間隙鎖策略防止幻讀的出現，間隙鎖使得InnoDB不僅僅對鎖定查詢涉及的行，還會對索引中的間隙進行鎖定，以防止幻影行的插入，

不好搞，建議：

推薦：官方檔案：InnoDB事務模型和鎖
翻譯版：https://www.cnblogs.com/EmptyRabbit/p/13688580.html

建議：更深入的了解一下InnoDB的MVCC架構，

其他的引擎嘛，其實我只喜歡InnoDB，，，
葉公好龍哈哈哈

其他存盤引擎

MyISAM

特性：

1. 加鎖與并發：表鎖，讀寫鎖
2. 修復：可手動或自動執行檢查和修復作業，就是慢了點，
3. 索引特性：支持全文索引
4. 性能：設計簡單，在某些情況下性能很好，嗯，某些情況下，

CSV引擎

CSV引擎可以將普通的CSV檔案作為MySQL的表來處理，但這種表并不支持索引，CSV引擎可以在資料庫運行的時候拷入或拷出檔案，因此CSV作為一種資料交換的機制，非常有用，

Memory引擎

如果需要快速的訪問資料，并且這些資料不會被修改，重啟后丟失也沒有關系，那么可以使用Memory表，因為所有資料都保存在記憶體中，不需要進行磁盤IO，
Memory表的結構在重啟以后還會保留，但資料會丟失，

先到這里啦，我努力了，接下來就看各位的努力了，三連走起！！！