MySQL中的鎖(表鎖、行鎖) MySQL中的鎖(表鎖、行鎖)
阿新 • • 發佈:2018-11-07
MySQL中的鎖(表鎖、行鎖)
鎖是計算機協調多個程序或純執行緒併發訪問某一資源的機制。在資料庫中,除傳統的計算資源(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在執行查詢語句(SELECT)前,會自動給涉及的所有表加讀鎖,在執行更新操作(UPDATE、DELETE、INSERT等)前,會自動給涉及的表加寫鎖,這個過程並不需要使用者干預,因此使用者一般不需要直接用LOCK TABLE命令給MyISAM表顯式加鎖。在本書的示例中,顯式加鎖基本上都是為了方便而已,並非必須如此。 給MyISAM表顯示加鎖,一般是為了一定程度模擬事務操作,實現對某一時間點多個表的一致性讀取。例如,有一個訂單表orders,其中記錄有訂單的總金額total,同時還有一個訂單明細表order_detail,其中記錄有訂單每一產品的金額小計subtotal,假設我們需要檢查這兩個表的金額合計是否相等,可能就需要執行如下兩條SQL:1 2 |
SELECT
SUM
(total)
FROM
orders;
SELECT
SUM
(subtotal)
FROM
order_detail;
|
1 2 3 4 |
LOCK tables orders
read
local
,order_detail
read
local
;
SELECT
SUM
(total)
FROM
orders;
SELECT
SUM
(subtotal)
FROM
order_detail;
Unlock tables;
|
- 上面的例子在LOCK TABLES時加了‘local’選項,其作用就是在滿足MyISAM表併發插入條件的情況下,允許其他使用者在表尾插入記錄
- 在用LOCKTABLES給表顯式加表鎖是時,必須同時取得所有涉及表的鎖,並且MySQL支援鎖升級。也就是說,在執行LOCK TABLES後,只能訪問顯式加鎖的這些表,不能訪問未加鎖的表;同時,如果加的是讀鎖,那麼只能執行查詢操作,而不能執行更新操作。其實,在自動加鎖的情況下也基本如此,MySQL問題一次獲得SQL語句所需要的全部鎖。這也正是MyISAM表不會出現死鎖(Deadlock Free)的原因
併發鎖
在一定條件下,MyISAM也支援查詢和操作的併發進行。 MyISAM儲存引擎有一個系統變數concurrent_insert,專門用以控制其併發插入的行為,其值分別可以為0、1或2。- 當concurrent_insert設定為0時,不允許併發插入。
- 當concurrent_insert設定為1時,如果MyISAM允許在一個讀表的同時,另一個程序從表尾插入記錄。這也是MySQL的預設設定。
- 當concurrent_insert設定為2時,無論MyISAM表中有沒有空洞,都允許在表尾插入記錄,都允許在表尾併發插入記錄。
MyISAM的鎖排程
前面講過,MyISAM儲存引擎的讀和寫鎖是互斥,讀操作是序列的。那麼,一個程序請求某個MyISAM表的讀鎖,同時另一個程序也請求同一表的寫鎖,MySQL如何處理呢?答案是寫程序先獲得鎖。不僅如此,即使讀程序先請求先到鎖等待佇列,寫請求後到,寫鎖也會插到讀請求之前!這是因為MySQL認為寫請求一般比讀請求重要。這也正是MyISAM表不太適合於有大量更新操作和查詢操作應用的原因,因為,大量的更新操作會造成查詢操作很難獲得讀鎖,從而可能永遠阻塞。這種情況有時可能會變得非常糟糕!幸好我們可以通過一些設定來調節MyISAM的排程行為。- 通過指定啟動引數low-priority-updates,使MyISAM引擎預設給予讀請求以優先的權利。
- 通過執行命令SET LOW_PRIORITY_UPDATES=1,使該連線發出的更新請求優先順序降低。
- 通過指定INSERT、UPDATE、DELETE語句的LOW_PRIORITY屬性,降低該語句的優先順序。
InnoDB鎖問題
InnoDB與MyISAM的最大不同有兩點:一是支援事務(TRANSACTION);二是採用了行級鎖。 行級鎖和表級鎖本來就有許多不同之處,另外,事務的引入也帶來了一些新問題。1.事務(Transaction)及其ACID屬性
事務是由一組SQL語句組成的邏輯處理單元,事務具有4屬性,通常稱為事務的ACID屬性。- 原性性(Actomicity):事務是一個原子操作單元,其對資料的修改,要麼全都執行,要麼全都不執行。
- 一致性(Consistent):在事務開始和完成時,資料都必須保持一致狀態。這意味著所有相關的資料規則都必須應用於事務的修改,以操持完整性;事務結束時,所有的內部資料結構(如B樹索引或雙向連結串列)也都必須是正確的。
- 隔離性(Isolation):資料庫系統提供一定的隔離機制,保證事務在不受外部併發操作影響的“獨立”環境執行。這意味著事務處理過程中的中間狀態對外部是不可見的,反之亦然。
- 永續性(Durable):事務完成之後,它對於資料的修改是永久性的,即使出現系統故障也能夠保持。
2.併發事務帶來的問題
相對於序列處理來說,併發事務處理能大大增加資料庫資源的利用率,提高資料庫系統的事務吞吐量,從而可以支援可以支援更多的使用者。但併發事務處理也會帶來一些問題,主要包括以下幾種情況。- 更新丟失(Lost Update):當兩個或多個事務選擇同一行,然後基於最初選定的值更新該行時,由於每個事務都不知道其他事務的存在,就會發生丟失更新問題——最後的更新覆蓋了其他事務所做的更新。例如,兩個編輯人員製作了同一文件的電子副本。每個編輯人員獨立地更改其副本,然後儲存更改後的副本,這樣就覆蓋了原始文件。最後儲存其更改儲存其更改副本的編輯人員覆蓋另一個編輯人員所做的修改。如果在一個編輯人員完成並提交事務之前,另一個編輯人員不能訪問同一檔案,則可避免此問題
- 髒讀(Dirty Reads):一個事務正在對一條記錄做修改,在這個事務並提交前,這條記錄的資料就處於不一致狀態;這時,另一個事務也來讀取同一條記錄,如果不加控制,第二個事務讀取了這些“髒”的資料,並據此做進一步的處理,就會產生未提交的資料依賴關係。這種現象被形象地叫做“髒讀”。
- 不可重複讀(Non-Repeatable Reads):一個事務在讀取某些資料已經發生了改變、或某些記錄已經被刪除了!這種現象叫做“不可重複讀”。
- 幻讀(Phantom Reads):一個事務按相同的查詢條件重新讀取以前檢索過的資料,卻發現其他事務插入了滿足其查詢條件的新資料,這種現象就稱為“幻讀”。
3.事務隔離級別
在併發事務處理帶來的問題中,“更新丟失”通常應該是完全避免的。但防止更新丟失,並不能單靠資料庫事務控制器來解決,需要應用程式對要更新的資料 加必要的鎖來解決,因此,防止更新丟失應該是應用的責任。 “髒讀”、“不可重複讀”和“幻讀”,其實都是資料庫讀一致性問題,必須由資料庫提供一定的事務隔離機制來解決。資料庫實現事務隔離的方式,基本可以分為以下兩種。 一種是在讀取資料前,對其加鎖,阻止其他事務對資料進行修改。 另一種是不用加任何鎖,通過一定機制生成一個數據請求時間點的一致性資料快照(Snapshot),並用這個快照來提供一定級別(語句級或事務級)的一致性讀取。從使用者的角度,好像是資料庫可以提供同一資料的多個版本,因此,這種技術叫做資料多版本併發控制(MultiVersion Concurrency Control,簡稱MVCC或MCC),也經常稱為多版本資料庫。 資料庫的事務隔離級別越嚴格,併發副作用越小,但付出的代價也就越大,因為事務隔離實質上就是使事務在一定程度上“序列化”進行,這顯然與“併發”是矛盾的,同時,不同的應用對讀一致性和事務隔離程度的要求也是不同的,比如許多應用對“不可重複讀”和“幻讀”並不敏感,可能更關心資料併發訪問的能力。 為了解決“隔離”與“併發”的矛盾,ISO/ANSI SQL92定義了4個事務隔離級別,每個級別的隔離程度不同,允許出現的副作用也不同,應用可以根據自己業務邏輯要求,通過選擇不同的隔離級別來平衡"隔離"與"併發"的矛盾事務4種隔離級別比較
隔離級別/讀資料一致性及允許的併發副作用 | 讀資料一致性 | 髒讀 | 不可重複讀 | 幻讀 |
未提交讀(Read uncommitted) | 最低級別,只能保證不讀取物理上損壞的資料 | 是 | 是 | 是 |
已提交度(Read committed) | 語句級 | 否 | 是 | 是 |
可重複讀(Repeatable read) | 事務級 | 否 | 否 | 是 |
可序列化(Serializable) | 最高級別,事務級 | 否 | 否 | 否 |
獲取InonoD行鎖爭用情況
可以通過檢查InnoDB_row_lock狀態變數來分析系統上的行鎖的爭奪情況:1 2 3 4 5 6 7 8 9 10 11 |
mysql> show status
like
'innodb_row_lock%'
;
+
-------------------------------+-------+
| Variable_name | Value |
+
-------------------------------+-------+
| Innodb_row_lock_current_waits | 0 |
| Innodb_row_lock_time | 0 |
| Innodb_row_lock_time_avg | 0 |
| Innodb_row_lock_time_max | 0 |
| Innodb_row_lock_waits | 0 |
+
-------------------------------+-------+
5
rows
in
set
(0.00 sec)
|
InnoDB的行鎖模式及加鎖方法
InnoDB實現了以下兩種型別的行鎖。- 共享鎖(s):允許一個事務去讀一行,阻止其他事務獲得相同資料集的排他鎖。
- 排他鎖(X):允許獲取排他鎖的事務更新資料,阻止其他事務取得相同的資料集共享讀鎖和排他寫鎖。
InnoDB行鎖模式相容性列表
當前鎖模式/是否相容/請求鎖模式 | X | IX | S | IS |
X | 衝突 | 衝突 | 衝突 | 衝突 |
IX | 衝突 | 相容 | 衝突 | 相容 |
S | 衝突 | 衝突 | 相容 | 相容 |
IS | 衝突 | 相容 | 相容 | 相容 |
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表的理由。但在個另特殊事務中,也可以考慮使用表級鎖。- 第一種情況是:事務需要更新大部分或全部資料,表又比較大,如果使用預設的行鎖,不僅這個事務執行效率低,而且可能造成其他事務長時間鎖等待和鎖衝突,這種情況下可以考慮使用表鎖來提高該事務的執行速度。
- 第二種情況是:事務涉及多個表,比較複雜,很可能引起死鎖,造成大量事務回滾。這種情況也可以考慮一次性鎖定事務涉及的表,從而避免死鎖、減少資料庫因事務回滾帶來的開銷。
1 2 3 4 5 |
SET
AUTOCOMMIT=0;
LOCAK TABLES t1 WRITE, t2
READ
, ...;
[do something
with
tables t1
and
here];
COMMIT
;
UNLOCK TABLES;
|
關於死鎖
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調整等措施減少鎖衝突和死鎖,包括:- 儘量使用較低的隔離級別
- 精心設計索引,並儘量使用索引訪問資料,使加鎖更精確,從而減少鎖衝突的機會。
- 選擇合理的事務大小,小事務發生鎖衝突的機率也更小。
- 給記錄集顯示加鎖時,最好一次性請求足夠級別的鎖。比如要修改資料的話,最好直接申請排他鎖,而不是先申請共享鎖,修改時再請求排他鎖,這樣容易產生死鎖。
- 不同的程式訪問一組表時,應儘量約定以相同的順序訪問各表,對一個表而言,儘可能以固定的順序存取表中的行。這樣可以大減少死鎖的機會。
- 儘量用相等條件訪問資料,這樣可以避免間隙鎖對併發插入的影響。
- 不要申請超過實際需要的鎖級別;除非必須,查詢時不要顯示加鎖。
- 對於一些特定的事務,可以使用表鎖來提高處理速度或減少死鎖的可能。
鎖是計算機協調多個程序或純執行緒併發訪問某一資源的機制。在資料庫中,除傳統的計算資源(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在執行查詢語句(SELECT)前,會自動給涉及的所有表加讀鎖,在執行更新操作(UPDATE、DELETE、INSERT等)前,會自動給涉及的表加寫鎖,這個過程並不需要使用者干預,因此使用者一般不需要直接用LOCK TABLE命令給MyISAM表顯式加鎖。在本書的示例中,顯式加鎖基本上都是為了方便而已,並非必須如此。 給MyISAM表顯示加鎖,一般是為了一定程度模擬事務操作,實現對某一時間點多個表的一致性讀取。例如,有一個訂單表orders,其中記錄有訂單的總金額total,同時還有一個訂單明細表order_detail,其中記錄有訂單每一產品的金額小計subtotal,假設我們需要檢查這兩個表的金額合計是否相等,可能就需要執行如下兩條SQL:1 2 |
SELECT
SUM
(total)
FROM
orders;
SELECT
SUM
(subtotal)
FROM
order_detail;
|
1 2 3 4 |
LOCK tables orders
read
local
,order_detail
read
local
;
SELECT
SUM
(total)
FROM
orders;
SELECT
SUM
(subtotal)
FROM
order_detail;
Unlock tables;
|
- 上面的例子在LOCK TABLES時加了‘local’選項,其作用就是在滿足MyISAM表併發插入條件的情況下,允許其他使用者在表尾插入記錄
- 在用LOCKTABLES給表顯式加表鎖是時,必須同時取得所有涉及表的鎖,並且MySQL支援鎖升級。也就是說,在執行LOCK TABLES後,只能訪問顯式加鎖的這些表,不能訪問未加鎖的表;同時,如果加的是讀鎖,那麼只能執行查詢操作,而不能執行更新操作。其實,在自動加鎖的情況下也基本如此,MySQL問題一次獲得SQL語句所需要的全部鎖。這也正是MyISAM表不會出現死鎖(Deadlock Free)的原因
併發鎖
在一定條件下,MyISAM也支援查詢和操作的併發進行。 MyISAM儲存引擎有一個系統變數concurrent_insert,專門用以控制其併發插入的行為,其值分別可以為0、1或2。- 當concurrent_insert設定為0時,不允許併發插入。
- 當concurrent_insert設定為1時,如果MyISAM允許在一個讀表的同時,另一個程序從表尾插入記錄。這也是MySQL的預設設定。
- 當concurrent_insert設定為2時,無論MyISAM表中有沒有空洞,都允許在表尾插入記錄,都允許在表尾併發插入記錄。
MyISAM的鎖排程
前面講過,MyISAM儲存引擎的讀和寫鎖是互斥,讀操作是序列的。那麼,一個程序請求某個MyISAM表的讀鎖,同時另一個程序也請求同一表的寫鎖,MySQL如何處理呢?答案是寫程序先獲得鎖。不僅如此,即使讀程序先請求先到鎖等待佇列,寫請求後到,寫鎖也會插到讀請求之前!這是因為MySQL認為寫請求一般比讀請求重要。這也正是MyISAM表不太適合於有大量更新操作和查詢操作應用的原因,因為,大量的更新操作會造成查詢操作很難獲得讀鎖,從而可能永遠阻塞。這種情況有時可能會變得非常糟糕!幸好我們可以通過一些設定來調節MyISAM的排程行為。- 通過指定啟動引數low-priority-updates,使MyISAM引擎預設給予讀請求以優先的權利。
- 通過執行命令SET LOW_PRIORITY_UPDATES=1,使該連線發出的更新請求優先順序降低。
- 通過指定INSERT、UPDATE、DELETE語句的LOW_PRIORITY屬性,降低該語句的優先順序。
InnoDB鎖問題
InnoDB與MyISAM的最大不同有兩點:一是支援事務(TRANSACTION);二是採用了行級鎖。 行級鎖和表級鎖本來就有許多不同之處,另外,事務的引入也帶來了一些新問題。1.事務(Transaction)及其ACID屬性
事務是由一組SQL語句組成的邏輯處理單元,事務具有4屬性,通常稱為事務的ACID屬性。- 原性性(Actomicity):事務是一個原子操作單元,其對資料的修改,要麼全都執行,要麼全都不執行。
- 一致性(Consistent):在事務開始和完成時,資料都必須保持一致狀態。這意味著所有相關的資料規則都必須應用於事務的修改,以操持完整性;事務結束時,所有的內部資料結構(如B樹索引或雙向連結串列)也都必須是正確的。
- 隔離性(Isolation):資料庫系統提供一定的隔離機制,保證事務在不受外部併發操作影響的“獨立”環境執行。這意味著事務處理過程中的中間狀態對外部是不可見的,反之亦然。
- 永續性(Durable):事務完成之後,它對於資料的修改是永久性的,即使出現系統故障也能夠保持。
2.併發事務帶來的問題
相對於序列處理來說,併發事務處理能大大增加資料庫資源的利用率,提高資料庫系統的事務吞吐量,從而可以支援可以支援更多的使用者。但併發事務處理也會帶來一些問題,主要包括以下幾種情況。- 更新丟失(Lost Update):當兩個或多個事務選擇同一行,然後基於最初選定的值更新該行時,由於每個事務都不知道其他事務的存在,就會發生丟失更新問題——最後的更新覆蓋了其他事務所做的更新。例如,兩個編輯人員製作了同一文件的電子副本。每個編輯人員獨立地更改其副本,然後儲存更改後的副本,這樣就覆蓋了原始文件。最後儲存其更改儲存其更改副本的編輯人員覆蓋另一個編輯人員所做的修改。如果在一個編輯人員完成並提交事務之前,另一個編輯人員不能訪問同一檔案,則可避免此問題
- 髒讀(Dirty Reads):一個事務正在對一條記錄做修改,在這個事務並提交前,這條記錄的資料就處於不一致狀態;這時,另一個事務也來讀取同一條記錄,如果不加控制,第二個事務讀取了這些“髒”的資料,並據此做進一步的處理,就會產生未提交的資料依賴關係。這種現象被形象地叫做“髒讀”。
- 不可重複讀(Non-Repeatable Reads):一個事務在讀取某些資料已經發生了改變、或某些記錄已經被刪除了!這種現象叫做“不可重複讀”。
- 幻讀(Phantom Reads):一個事務按相同的查詢條件重新讀取以前檢索過的資料,卻發現其他事務插入了滿足其查詢條件的新資料,這種現象就稱為“幻讀”。
3.事務隔離級別
在併發事務處理帶來的問題中,“更新丟失”通常應該是完全避免的。但防止更新丟失,並不能單靠資料庫事務控制器來解決,需要應用程式對要更新的資料 加必要的鎖來解決,因此,防止更新丟失應該是應用的責任。 “髒讀”、“不可重複讀”和“幻讀”,其實都是資料庫讀一致性問題,必須由資料庫提供一定的事務隔離機制來解決。資料庫實現事務隔離的方式,基本可以分為以下兩種。 一種是在讀取資料前,對其加鎖,阻止其他事務對資料進行修改。 另一種是不用加任何鎖,通過一定機制生成一個數據請求時間點的一致性資料快照(Snapshot),並用這個快照來提供一定級別(語句級或事務級)的一致性讀取。從使用者的角度,好像是資料庫可以提供同一資料的多個版本,因此,這種技術叫做資料多版本併發控制(MultiVersion Concurrency Control,簡稱MVCC或MCC),也經常稱為多版本資料庫。 資料庫的事務隔離級別越嚴格,併發副作用越小,但付出的代價也就越大,因為事務隔離實質上就是使事務在一定程度上“序列化”進行,這顯然與“併發”是矛盾的,同時,不同的應用對讀一致性和事務隔離程度的要求也是不同的,比如許多應用對“不可重複讀”和“幻讀”並不敏感,可能更關心資料併發訪問的能力。 為了解決“隔離”與“併發”的矛盾,ISO/ANSI SQL92定義了4個事務隔離級別,每個級別的隔離程度不同,允許出現的副作用也不同,應用可以根據自己業務邏輯要求,通過選擇不同的隔離級別來平衡"隔離"與"併發"的矛盾事務4種隔離級別比較
隔離級別/讀資料一致性及允許的併發副作用 | 讀資料一致性 | 髒讀 | 不可重複讀 | 幻讀 |
未提交讀(Read uncommitted) | 最低級別,只能保證不讀取物理上損壞的資料 | 是 | 是 | 是 |
已提交度(Read committed) | 語句級 | 否 | 是 | 是 |
可重複讀(Repeatable read) | 事務級 | 否 | 否 | 是 |
可序列化(Serializable) | 最高級別,事務級 | 否 | 否 | 否 |