之前寫了關於mysql的事務,這裏補充一篇關於mysql鎖的文章,這裏是轉發https://www.cnblogs.com/chenqionghe/p/4845693.html
的文章(這篇文章講的畢竟詳細,我改動了裏面一點錯誤),內容略有改動。
鎖是計算機協調多個進程或純線程併發訪問某一資源的機制。在數據庫中,除傳統的計算資源(CPU、RAM、I/O)的爭用以外,數據也是一種供許多用戶共享的資源。如何保證數據併發訪問的一致性、有效性是所在有數據庫必須解決的一個問題,鎖衝突也是影響數據庫併發訪問性能的一個重要因素。從這個角度來說,鎖對數據庫而言顯得尤其重要,也更加複雜。
概述
相對其他數據庫而言,MySQL的鎖機制比較簡單,其最顯著的特點是不同的存儲引擎支持不同的鎖機制。
MySQL大致可歸納爲以下3種鎖:
- 表級鎖:開銷小,加鎖快;不會出現死鎖;鎖定粒度大,發生鎖衝突的概率最高,併發度最低。
- 行級鎖:開銷大,加鎖慢;會出現死鎖;鎖定粒度最小,發生鎖衝突的概率最低,併發度也最高。
- 頁面鎖:開銷和加鎖時間界於表鎖和行鎖之間;會出現死鎖;鎖定粒度界於表鎖和行鎖之間,併發度一般
----------------------------------------------------------------------
MySQL表級鎖的鎖模式(MyISAM)
MySQL表級鎖有兩種模式:表共享鎖(Table Read Lock)和表獨佔寫鎖(Table Write Lock)。
- 對MyISAM的讀操作,不會阻塞其他用戶對同一表請求,但會阻塞對同一表的寫請求;
- 對MyISAM的寫操作,則會阻塞其他用戶對同一表的讀和寫操作;
- MyISAM表的讀操作和寫操作之間,以及寫操作之間是串行的。
當一個線程獲得對一個表的寫鎖後,只有持有鎖線程可以對錶進行更新操作。其他線程的讀、寫操作都會等待,直到鎖被釋放爲止。
MySQL表級鎖的鎖模式
MySQL的表鎖有兩種模式:表共享讀鎖(Table Read Lock)和表獨佔寫鎖(Table Write Lock)。鎖模式的兼容如下表
MySQL中的表鎖兼容性
當前鎖模式/是否兼容/請求鎖模式 |
None |
讀鎖 |
寫鎖 |
讀鎖 | 是 | 是 | 否 |
寫鎖 | 是 | 否 | 否 |
可見,對MyISAM表的讀操作,不會阻塞其他用戶對同一表的讀請求,但會阻塞對同一表的寫請求;對MyISAM表的寫操作,則會阻塞其他用戶對同一表的讀和寫請求;MyISAM表的讀和寫操作之間,以及寫和寫操作之間是串行的!(當一線程獲得對一個表的寫鎖後,只有持有鎖的線程可以對錶進行更新操作。其他線程的讀、寫操作都會等待,直到鎖被釋放爲止。)
如何加表鎖
MyISAM在執行查詢語句(SELECT)前,會自動給涉及的所有表加讀鎖,在執行更新操作(UPDATE、DELETE、INSERT等)前,會自動給涉及的表加寫鎖,這個過程並不需要用戶干預,因此用戶一般不需要直接用LOCK TABLE命令給MyISAM表顯式加鎖。在本書的示例中,顯式加鎖基本上都是爲了方便而已,並非必須如此。
給MyISAM表顯示加鎖,一般是爲了一定程度模擬事務操作,實現對某一時間點多個表的一致性讀取。例如,有一個訂單表orders,其中記錄有訂單的總金額total,同時還有一個訂單明細表order_detail,其中記錄有訂單每一產品的金額小計subtotal,假設我們需要檢查這兩個表的金額合計是否相等,可能就需要執行如下兩條SQL:
1 2 |
|
這時,如果不先給這兩個表加鎖,就可能產生錯誤的結果,因爲第一條語句執行過程中,order_detail表可能已經發生了改變。因此,正確的方法應該是:
1 2 3 4 |
|
要特別說明以下兩點內容。
- 上面的例子在LOCK TABLES時加了‘local’選項,其作用就是在滿足MyISAM表併發插入條件的情況下,允許其他用戶在表尾插入記錄
- 在用LOCKTABLES給表顯式加表鎖是時,必須同時取得所有涉及表的鎖,並且MySQL支持鎖升級。也就是說,在執行LOCK TABLES後,只能訪問顯式加鎖的這些表,不能訪問未加鎖的表;同時,如果加的是讀鎖,那麼只能執行查詢操作,而不能執行更新操作。其實,在自動加鎖的情況下也基本如此,MySQL問題一次獲得SQL語句所需要的全部鎖。這也正是MyISAM表不會出現死鎖(Deadlock Free)的原因
一個session使用LOCK TABLE 命令給表film_text加了讀鎖,這個session可以查詢鎖定表中的記錄,但更新或訪問其他表都會提示錯誤;同時,另外一個session可以查詢表中的記錄,但更新就會出現鎖等待。
當使用LOCK TABLE時,不僅需要一次鎖定用到的所有表,而且,同一個表在SQL語句中出現多少次,就要通過與SQL語句中相同的別名鎖多少次,否則也會出錯!
併發鎖
在一定條件下,MyISAM也支持查詢和操作的併發進行。
MyISAM存儲引擎有一個系統變量concurrent_insert,專門用以控制其併發插入的行爲,其值分別可以爲0、1或2。
- 當concurrent_insert設置爲0時,不允許併發插入。
- 當concurrent_insert設置爲1時,如果MyISAM允許在一個讀表的同時,另一個進程從表尾插入記錄。這也是MySQL的默認設置。
- 當concurrent_insert設置爲2時,無論MyISAM表中有沒有空洞,都允許在表尾插入記錄,都允許在表尾併發插入記錄。
可以利用MyISAM存儲引擎的併發插入特性,來解決應用中對同一表查詢和插入鎖爭用。例如,將concurrent_insert系統變量爲2,總是允許併發插入;同時,通過定期在系統空閒時段執行OPTIONMIZE 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);二是採用了行級鎖。
行級鎖和表級鎖本來就有許多不同之處,另外,事務的引入也帶來了一些新問題。
獲取InonoD行鎖爭用情況
可以通過檢查InnoDB_row_lock狀態變量來分析系統上的行鎖的爭奪情況:
1 2 3 4 5 6 7 8 9 10 11 |
|
如果發現爭用比較嚴重,如Innodb_row_lock_waits和Innodb_row_lock_time_avg的值比較高,還可以通過設置InnoDB Monitors來進一步觀察發生鎖衝突的表、數據行等,並分析鎖爭用的原因。
InnoDB的行鎖模式及加鎖方法
InnoDB實現了以下兩種類型的行鎖。
- 共享鎖(s):允許一個事務去讀一行,允許其他事務讀取相同內容,阻止其他事務更改相同數據集
- 排他鎖(X):允許獲取排他鎖的事務更新數據,阻止其他事務取得相同的數據集共享讀鎖和排他寫鎖。
另外,爲了允許行鎖和表鎖共存,實現多粒度鎖機制,InnoDB還有兩種內部使用的意向鎖(Intention Locks),這兩種意向鎖都是表鎖。
意向共享鎖(IS):事務打算給數據行共享鎖,事務在給一個數據行加共享鎖前必須先取得該表的IS鎖。
意向排他鎖(IX):事務打算給數據行加排他鎖,事務在給一個數據行加排他鎖前必須先取得該表的IX鎖。
InnoDB行鎖模式兼容性列表
當前鎖模式/是否兼容/請求鎖模式 | X | IX | S | IS |
X | 衝突 | 衝突 | 衝突 | 衝突 |
IX | 衝突 | 兼容 | 衝突 | 兼容 |
S | 衝突 | 衝突 | 兼容 | 兼容 |
IS | 衝突 | 兼容 | 兼容 | 兼容 |
如果一個事務請求的鎖模式與當前的鎖兼容,InnoDB就請求的鎖授予該事務;反之,如果兩者兩者不兼容,該事務就要等待鎖釋放。
意向鎖是InnoDB自動加的,不需用戶干預。對於UPDATE、DELETE和INSERT語句,InnoDB會自動給涉及及數據集加排他鎖(X);對於普通SELECT語句,InnoDB不會加任何鎖;事務可以通過以下語句顯示給記錄集加共享鎖或排鎖。
共享鎖(S):SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE
排他鎖(X):SELECT * FROM table_name WHERE ... FOR UPDATE
用SELECT .. IN SHARE MODE獲得共享鎖,主要用在需要數據依存關係時確認某行記錄是否存在,並確保沒有人對這個記錄進行UPDATE或者DELETE操作。但是如果當前事務也需要對該記錄進行更新操作,則很有可能造成死鎖,對於鎖定行記錄後需要進行更新操作的應用,應該使用SELECT ... FOR UPDATE方式獲取排他鎖。
InnoDB行鎖實現方式
InnoDB行鎖是通過索引上的索引項來實現的,這一點MySQL與Oracle不同,後者是通過在數據中對相應數據行加鎖來實現的。InnoDB這種行鎖實現特點意味者:只有通過索引條件檢索數據,InnoDB纔會使用行級鎖,否則,InnoDB將使用表鎖!
在實際應用中,要特別注意InnoDB行鎖的這一特性,不然的話,可能導致大量的鎖衝突,從而影響併發性能。
間隙鎖(Next-Key鎖)
當我們用範圍條件而不是相等條件檢索數據,並請求共享或排他鎖時,InnoDB會給符合條件的已有數據的索引項加鎖;對於鍵值在條件範圍內但並不存在的記錄,叫做“間隙(GAP)”,InnoDB也會對這個“間隙”加鎖,這種鎖機制就是所謂的間隙鎖(Next-Key鎖)。
舉例來說,假如emp表中只有101條記錄,其empid的值分別是1,2,...,100,101,下面的SQL:
SELECT * FROM emp WHERE empid > 100 FOR UPDATE
是一個範圍條件的檢索,InnoDB不僅會對符合條件的empid值爲101的記錄加鎖,也會對empid大於101(這些記錄並不存在)的“間隙”加鎖。
InnoDB使用間隙鎖的目的,一方面是爲了防止幻讀,以滿足相關隔離級別的要求,對於上面的例子,要是不使用間隙鎖,如果其他事務插入了empid大於100的任何記錄,那麼本事務如果再次執行上述語句,就會發生幻讀;另一方面,是爲了滿足其恢復和複製的需要。有關其恢復和複製對機制的影響,以及不同隔離級別下InnoDB使用間隙鎖的情況。
很顯然,在使用範圍條件檢索並鎖定記錄時,InnoDB這種加鎖機制會阻塞符合條件範圍內鍵值的併發插入,這往往會造成嚴重的鎖等待。因此,在實際開發中,尤其是併發插入比較多的應用,我們要儘量優化業務邏輯,儘量使用相等條件來訪問更新數據,避免使用範圍條件。
什麼時候使用表鎖
對於InnoDB表,在絕大部分情況下都應該使用行級鎖,因爲事務和行鎖往往是我們之所以選擇InnoDB表的理由。但在個另特殊事務中,也可以考慮使用表級鎖。
- 第一種情況是:事務需要更新大部分或全部數據,表又比較大,如果使用默認的行鎖,不僅這個事務執行效率低,而且可能造成其他事務長時間鎖等待和鎖衝突,這種情況下可以考慮使用表鎖來提高該事務的執行速度。
- 第二種情況是:事務涉及多個表,比較複雜,很可能引起死鎖,造成大量事務回滾。這種情況也可以考慮一次性鎖定事務涉及的表,從而避免死鎖、減少數據庫因事務回滾帶來的開銷。
當然,應用中這兩種事務不能太多,否則,就應該考慮使用MyISAM表。
在InnoDB下 ,使用表鎖要注意以下兩點。
(1)使用LOCK TALBES雖然可以給InnoDB加表級鎖,但必須說明的是,表鎖不是由InnoDB存儲引擎層管理的,而是由其上一層MySQL Server負責的,僅當autocommit=0、innodb_table_lock=1(默認設置)時,InnoDB層才能知道MySQL加的表鎖,MySQL Server才能感知InnoDB加的行鎖,這種情況下,InnoDB才能自動識別涉及表級鎖的死鎖;否則,InnoDB將無法自動檢測並處理這種死鎖。
(2)在用LOCAK TABLES對InnoDB鎖時要注意,要將AUTOCOMMIT設爲0,否則MySQL不會給表加鎖;事務結束前,不要用UNLOCAK TABLES釋放表鎖,因爲UNLOCK TABLES會隱含地提交事務;COMMIT或ROLLBACK產不能釋放用LOCAK TABLES加的表級鎖,必須用UNLOCK TABLES釋放表鎖,正確的方式見如下語句。
例如,如果需要寫表t1並從表t讀,可以按如下做:
1 2 3 4 5 |
|
關於死鎖
MyISAM表鎖是deadlock free的,這是因爲MyISAM總是一次性獲得所需的全部鎖,要麼全部滿足,要麼等待,因此不會出現死鎖。但是在InnoDB中,除單個SQL組成的事務外,鎖是逐步獲得的,這就決定了InnoDB發生死鎖是可能的。
發生死鎖後,InnoDB一般都能自動檢測到,並使一個事務釋放鎖並退回,另一個事務獲得鎖,繼續完成事務。但在涉及外部鎖,或涉及鎖的情況下,InnoDB並不能完全自動檢測到死鎖,這需要通過設置鎖等待超時參數innodb_lock_wait_timeout來解決。需要說明的是,這個參數並不是只用來解決死鎖問題,在併發訪問比較高的情況下,如果大量事務因無法立即獲取所需的鎖而掛起,會佔用大量計算機資源,造成嚴重性能問題,甚至拖垮數據庫。我們通過設置合適的鎖等待超時閾值,可以避免這種情況發生。
通常來說,死鎖都是應用設計的問題,通過調整業務流程、數據庫對象設計、事務大小、以及訪問數據庫的SQL語句,絕大部分都可以避免。下面就通過實例來介紹幾種死鎖的常用方法。
(1)在應用中,如果不同的程序會併發存取多個表,應儘量約定以相同的順序爲訪問表,這樣可以大大降低產生死鎖的機會。如果兩個session訪問兩個表的順序不同,發生死鎖的機會就非常高!但如果以相同的順序來訪問,死鎖就可能避免。
(2)在程序以批量方式處理數據的時候,如果事先對數據排序,保證每個線程按固定的順序來處理記錄,也可以大大降低死鎖的可能。
(3)在事務中,如果要更新記錄,應該直接申請足夠級別的鎖,即排他鎖,而不應該先申請共享鎖,更新時再申請排他鎖,甚至死鎖。
(4)在REPEATEABLE-READ隔離級別下,如果兩個線程同時對相同條件記錄用SELECT...ROR UPDATE加排他鎖,在沒有符合該記錄情況下,兩個線程都會加鎖成功。程序發現記錄尚不存在,就試圖插入一條新記錄,如果兩個線程都這麼做,就會出現死鎖。這種情況下,將隔離級別改成READ COMMITTED,就可以避免問題。
(5)當隔離級別爲READ COMMITED時,如果兩個線程都先執行SELECT...FOR UPDATE,判斷是否存在符合條件的記錄,如果沒有,就插入記錄。此時,只有一個線程能插入成功,另一個線程會出現鎖等待,當第1個線程提交後,第2個線程會因主鍵重出錯,但雖然這個線程出錯了,卻會獲得一個排他鎖!這時如果有第3個線程又來申請排他鎖,也會出現死鎖。對於這種情況,可以直接做插入操作,然後再捕獲主鍵重異常,或者在遇到主鍵重錯誤時,總是執行ROLLBACK釋放獲得的排他鎖。
儘管通過上面的設計和優化等措施,可以大減少死鎖,但死鎖很難完全避免。因此,在程序設計中總是捕獲並處理死鎖異常是一個很好的編程習慣。
如果出現死鎖,可以用SHOW INNODB STATUS命令來確定最後一個死鎖產生的原因和改進措施。
--------------------------------------------------------------------------------
總結
對於MyISAM的表鎖,主要有以下幾點
(1)共享讀鎖(S)之間是兼容的,但共享讀鎖(S)和排他寫鎖(X)之間,以及排他寫鎖之間(X)是互斥的,也就是說讀和寫是串行的。
(2)在一定條件下,MyISAM允許查詢和插入併發執行,我們可以利用這一點來解決應用中對同一表和插入的鎖爭用問題。
(3)MyISAM默認的鎖調度機制是寫優先,這並不一定適合所有應用,用戶可以通過設置LOW_PRIPORITY_UPDATES參數,或在INSERT、UPDATE、DELETE語句中指定LOW_PRIORITY選項來調節讀寫鎖的爭用。
(4)由於表鎖的鎖定粒度大,讀寫之間又是串行的,因此,如果更新操作較多,MyISAM表可能會出現嚴重的鎖等待,可以考慮採用InnoDB表來減少鎖衝突。
對於InnoDB表,主要有以下幾點
(1)InnoDB的行銷是基於索引實現的,如果不通過索引訪問數據,InnoDB會使用表鎖。
(2)InnoDB間隙鎖機制,以及InnoDB使用間隙鎖的原因。
(3)在不同的隔離級別下,InnoDB的鎖機制和一致性讀策略不同。
(4)MySQL的恢復和複製對InnoDB鎖機制和一致性讀策略也有較大影響。
(5)鎖衝突甚至死鎖很難完全避免。
在瞭解InnoDB的鎖特性後,用戶可以通過設計和SQL調整等措施減少鎖衝突和死鎖,包括:
- 儘量使用較低的隔離級別
- 精心設計索引,並儘量使用索引訪問數據,使加鎖更精確,從而減少鎖衝突的機會。
- 選擇合理的事務大小,小事務發生鎖衝突的機率也更小。
- 給記錄集顯示加鎖時,最好一次性請求足夠級別的鎖。比如要修改數據的話,最好直接申請排他鎖,而不是先申請共享鎖,修改時再請求排他鎖,這樣容易產生死鎖。
- 不同的程序訪問一組表時,應儘量約定以相同的順序訪問各表,對一個表而言,儘可能以固定的順序存取表中的行。這樣可以大減少死鎖的機會。
- 儘量用相等條件訪問數據,這樣可以避免間隙鎖對併發插入的影響。
- 不要申請超過實際需要的鎖級別;除非必須,查詢時不要顯示加鎖。
- 對於一些特定的事務,可以使用表鎖來提高處理速度或減少死鎖的可能。