MYSQL引擎的鎖對比

 

 

悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿資料的時候都認為別人會修改，所以每次在拿資料的時候都會上鎖，這樣別人想拿這個資料就會block直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。

樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿資料的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個資料，可以使用版本號等機制。樂觀鎖適用於多讀的應用型別，這樣可以提高吞吐量，像資料庫如果提供類似於write_condition機制的其實都是提供的樂觀鎖。

兩種鎖各有優缺點，不可認為一種好於另一種，像樂觀鎖適用於寫比較少的情況下，即衝突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但如果經常產生衝突，上層應用會不斷的進行retry，這樣反倒是降低了效能，所以這種情況下用悲觀鎖就比較合適。

 

鎖是計算機協調多個程式或執行緒併發訪問某一資源的機制。如何保證資料併發訪問的一致性、有效性是所有資料庫必須解決的一個問題，鎖衝突也是影響資料庫併發訪問效能的一個重要因素。

 

MySQL鎖概述

MyISAM和MEMORY儲存引擎採用的是表級鎖（table-level locking）；BDB儲存引擎採用的是頁面鎖（page-level locking），但也支援表級鎖；InnoDB儲存引擎既支援行級鎖（row-level locking），也支援表級鎖，但預設情況下是採用行級鎖。

 

MySQL這3種鎖的特性可大致歸納如下。

開銷、加鎖速度、死鎖、粒度、併發效能

l        表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖衝突的概率最高,併發度最低。

l        行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的概率最低,併發度也最高。

l        頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，併發度一般。

表級鎖更適合於以查詢為主，只有少量按索引條件更新資料的應用，如Web應用；而行級鎖則更適合於有大量按索引條件併發更新少量不同資料，同時又有併發查詢的應用，如一些線上事務處理（OLTP）系統。

 

MySQL的表級鎖有兩種模式：表共享讀鎖（Table Read Lock）和表獨佔寫鎖（Table Write Lock）。鎖模式的相容性如表20-1所示。

表20-1                                           MySQL中的表鎖相容性                

請求鎖模式          是否相容 當前鎖模式	None	讀鎖	寫鎖
讀鎖	是	是	否
寫鎖	是	否	否

可見，對MyISAM表的讀操作，不會阻塞其他使用者對同一表的讀請求，但會阻塞對同一表的寫請求；對 MyISAM表的寫操作，則會阻塞其他使用者對同一表的讀和寫操作；MyISAM表的讀操作與寫操作之間，以及寫操作之間是序列的！根據如表20-2所示的例子可以知道，當一個執行緒獲得對一個表的寫鎖後，只有持有鎖的執行緒可以對錶進行更新操作。其他執行緒的讀、寫操作都會等待，直到鎖被釋放為止。

MyISAM在執行查詢語句（SELECT）前，會自動給涉及的所有表加讀鎖，在執行更新操作（UPDATE、DELETE、INSERT等）前，會自動給涉及的表加寫鎖，這個過程並不需要使用者干預，因此，使用者一般不需要直接用LOCK TABLE命令給MyISAM表顯式加鎖。

 

前面講過，MyISAM儲存引擎的讀鎖和寫鎖是互斥的，讀寫操作是序列的。那麼，一個程式請求某個MyISAM表的讀鎖，同時另一個程式也請求同一表的寫鎖，MySQL如何處理呢？答案是寫程式先獲得鎖。不僅如此，即使讀請求先到鎖等待佇列，寫請求後到，寫鎖也會插到讀鎖請求之前！這是因為MySQL認為寫請求一般比讀請求要重要。這也正是MyISAM表不太適合於有大量更新操作和查詢操作應用的原因，因為，大量的更新操作會造成查詢操作很難獲得讀鎖，從而可能永遠阻塞。這種情況有時可能會變得非常糟糕！幸好我們可以通過一些設定來調節MyISAM 的排程行為。

¡  通過指定啟動引數low-priority-updates，使MyISAM引擎預設給予讀請求以優先的權利。

¡  通過執行命令SET LOW_PRIORITY_UPDATES=1，使該連線發出的更新請求優先順序降低。

¡  通過指定INSERT、UPDATE、DELETE語句的LOW_PRIORITY屬性，降低該語句的優先順序。

雖然上面3種方法都是要麼更新優先，要麼查詢優先的方法，但還是可以用其來解決查詢相對重要的應用（如使用者登入系統）中，讀鎖等待嚴重的問題。

另外，MySQL也提供了一種折中的辦法來調節讀寫衝突，即給系統引數max_write_lock_count設定一個合適的值，當一個表的讀鎖達到這個值後，MySQL就暫時將寫請求的優先順序降低，給讀程式一定獲得鎖的機會。

上面已經討論了寫優先排程機制帶來的問題和解決辦法。這裡還要強調一點：一些需要長時間執行的查詢操作，也會使寫程式“餓死”！因此，應用中應儘量避免出現長時間執行的查詢操作，不要總想用一條SELECT語句來解決問題，因為這種看似巧妙的SQL語句，往往比較複雜，執行時間較長，在可能的情況下可以通過使用中間表等措施對SQL語句做一定的“分解”，使每一步查詢都能在較短時間完成，從而減少鎖衝突。如果複雜查詢不可避免，應儘量安排在資料庫空閒時段執行，比如一些定期統計可以安排在夜間執行。

 

 

 

InnoDB鎖問題

InnoDB與MyISAM的最大不同有兩點：一是支援事務（TRANSACTION）；二是採用了行級鎖。行級鎖與表級鎖本來就有許多不同之處，另外，事務的引入也帶來了一些新問題。下面我們先介紹一點背景知識，然後詳細討論InnoDB的鎖問題。

背景知識

1．事務（Transaction）及其ACID屬性

事務是由一組SQL語句組成的邏輯處理單元，事務具有以下4個屬性，通常簡稱為事務的ACID屬性。

l        原子性（Atomicity）：事務是一個原子操作單元，其對資料的修改，要麼全都執行，要麼全都不執行。

l        一致性（Consistent）：在事務開始和完成時，資料都必須保持一致狀態。這意味著所有相關的資料規則都必須應用於事務的修改，以保持資料的完整性；事務結束時，所有的內部資料結構（如B樹索引或雙向連結串列）也都必須是正確的。

l        隔離性（Isolation）：資料庫系統提供一定的隔離機制，保證事務在不受外部併發操作影響的“獨立”環境執行。這意味著事務處理過程中的中間狀態對外部是不可見的，反之亦然。

l        永續性（Durable）：事務完成之後，它對於資料的修改是永久性的，即使出現系統故障也能夠保持。

銀行轉帳就是事務的一個典型例子。

2．併發事務處理帶來的問題

相對於序列處理來說，併發事務處理能大大增加資料庫資源的利用率，提高資料庫系統的事務吞吐量，從而可以支援更多的使用者。但併發事務處理也會帶來一些問題，主要包括以下幾種情況。

l  更新丟失（Lost Update）：當兩個或多個事務選擇同一行，然後基於最初選定的值更新該行時，由於每個事務都不知道其他事務的存在，就會發生丟失更新問題－－最後的更新覆蓋了由其他事務所做的更新。例如，兩個編輯人員製作了同一文件的電子副本。每個編輯人員獨立地更改其副本，然後儲存更改後的副本，這樣就覆蓋了原始文件。最後儲存其更改副本的編輯人員覆蓋另一個編輯人員所做的更改。如果在一個編輯人員完成並提交事務之前，另一個編輯人員不能訪問同一檔案，則可避免此問題。

l  髒讀（Dirty Reads）：一個事務正在對一條記錄做修改，在這個事務完成並提交前，這條記錄的資料就處於不一致狀態；這時，另一個事務也來讀取同一條記錄，如果不加控制，第二個事務讀取了這些“髒”資料，並據此做進一步的處理，就會產生未提交的資料依賴關係。這種現象被形象地叫做"髒讀"。

l  不可重複讀（Non-Repeatable Reads）：一個事務在讀取某些資料後的某個時間，再次讀取以前讀過的資料，卻發現其讀出的資料已經發生了改變、或某些記錄已經被刪除了！這種現象就叫做“不可重複讀”。

l  幻讀（Phantom Reads）：一個事務按相同的查詢條件重新讀取以前檢索過的資料，卻發現其他事務插入了滿足其查詢條件的新資料，這種現象就稱為“幻讀”。

3．事務隔離級別

在上面講到的併發事務處理帶來的問題中，“更新丟失”通常是應該完全避免的。但防止更新丟失，並不能單靠資料庫事務控制器來解決，需要應用程式對要更新的資料加必要的鎖來解決，因此，防止更新丟失應該是應用的責任。

“髒讀”、“不可重複讀”和“幻讀”，其實都是資料庫讀一致性問題，必須由資料庫提供一定的事務隔離機制來解決。資料庫實現事務隔離的方式，基本上可分為以下兩種。

l  一種是在讀取資料前，對其加鎖，阻止其他事務對資料進行修改。

l  另一種是不用加任何鎖，通過一定機制生成一個資料請求時間點的一致性資料快照（Snapshot)，並用這個快照來提供一定級別（語句級或事務級）的一致性讀取。從使用者的角度來看，好像是資料庫可以提供同一資料的多個版本，因此，這種技術叫做資料多版本併發控制（MultiVersion Concurrency Control，簡稱MVCC或MCC），也經常稱為多版本資料庫。

資料庫的事務隔離越嚴格，併發副作用越小，但付出的代價也就越大，因為事務隔離實質上就是使事務在一定程度上 “序列化”進行，這顯然與“併發”是矛盾的。同時，不同的應用對讀一致性和事務隔離程度的要求也是不同的，比如許多應用對“不可重複讀”和“幻讀”並不敏感，可能更關心資料併發訪問的能力。

為了解決“隔離”與“併發”的矛盾，ISO/ANSI SQL92定義了4個事務隔離級別，每個級別的隔離程度不同，允許出現的副作用也不同，應用可以根據自己的業務邏輯要求，通過選擇不同的隔離級別來平衡 “隔離”與“併發”的矛盾。表20-5很好地概括了這4個隔離級別的特性。

表20-5                                            4種隔離級別比較

讀資料一致性及允許的併發副作用 隔離級別	讀資料一致性	髒讀	不可重複讀	幻讀
未提交讀（Read uncommitted）	最低階別，只能保證不讀取物理上損壞的資料	是	是	是
已提交度（Read committed）	語句級	否	是	是
可重複讀（Repeatable read）	事務級	否	否	是
可序列化（Serializable）	最高階別，事務級	否	否	否

最後要說明的是：各具體資料庫並不一定完全實現了上述4個隔離級別，例如，Oracle只提供Read committed和Serializable兩個標準隔離級別，另外還提供自己定義的Read only隔離級別；SQL Server除支援上述ISO/ANSI SQL92定義的4個隔離級別外，還支援一個叫做“快照”的隔離級別，但嚴格來說它是一個用MVCC實現的Serializable隔離級別。MySQL 支援全部4個隔離級別，但在具體實現時，有一些特點，比如在一些隔離級別下是採用MVCC一致性讀，但某些情況下又不是，這些內容在後面的章節中將會做進一步介紹。

InnoDB的行鎖模式及加鎖方法

InnoDB實現了以下兩種型別的行鎖。

l  共享鎖（S）：允許一個事務去讀一行，阻止其他事務獲得相同資料集的排他鎖。

共享鎖（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。

l  排他鎖（X)：允許獲得排他鎖的事務更新資料，阻止其他事務取得相同資料集的共享讀鎖和排他寫鎖。

排他鎖（X)：SELECT * FROM table_name WHERE ... FOR UPDATE。

另外，為了允許行鎖和表鎖共存，實現多粒度鎖機制，InnoDB還有兩種內部使用的意向鎖（Intention Locks），這兩種意向鎖都是表鎖。

l  意向共享鎖（IS）：事務打算給資料行加行共享鎖，事務在給一個資料行加共享鎖前必須先取得該表的IS鎖。

l  意向排他鎖（IX）：事務打算給資料行加行排他鎖，事務在給一個資料行加排他鎖前必須先取得該表的IX鎖。

 

 

 

InnoDB行鎖是通過給索引項加鎖實現的，如果沒有索引，InnoDB會通過隱藏的聚簇索引來對記錄加鎖。

也就是說：如果不通過索引條件檢索資料，那麼InnoDB將對錶中所有資料加鎖，實際效果跟表鎖一樣。

行鎖分為三種情形：

 

Record lock ：對索引項加鎖，即鎖定一條記錄。

Gap lock：對索引項之間的‘間隙’、對第一條記錄前的間隙或最後一條記錄後的間隙加鎖，即鎖定一個範圍的記錄，不包含記錄本身

Next-key Lock：鎖定一個範圍的記錄幷包含記錄本身（上面兩者的結合）。

 

 

 

死鎖：

 

 

我們說過MyISAM中是不會產生死鎖的，因為MyISAM總是一次性獲得所需的全部鎖，要麼全部滿足，要麼全部等待。而在InnoDB中，鎖是逐步獲得的，就造成了死鎖的可能