標籤:pap io7 run 隔離 狀態 特徵 c89 cbe 高效能
1.鎖為什麼需要鎖?因為資料庫要解決並發控制問題。在同一時刻,可能會有多個用戶端對錶中同一行記錄進行操作,比如有的在讀取該行資料,其他的嘗試去刪除它。為了保證資料的一致性,資料庫就要對這種並行作業進行控制,因此就有了鎖的概念。1.1鎖的分類從對資料操作的類型(讀\寫)分
讀鎖(共用鎖定):針對同一塊資料,多個讀操作可以同時進行而不會互相影響。
寫鎖(獨佔鎖定):當前寫操作沒有完成前,它會阻斷其他寫鎖和讀鎖。
大多數時候,MySQL鎖的內部管理都是透明的。
1.2鎖粒度(Lock granularity)為了儘可能提高資料庫的並發度,每次鎖定的資料範圍越小越好,理論上每次只鎖定當前操作的資料的方案會得到最大的並發度,但是管理鎖是很耗資源的事情(涉及擷取,檢查,釋放鎖等動作),因此資料庫系統需要在高並發響應和系統效能兩方面進行平衡,這樣就產生了“鎖粒度(Lock granularity)”的概念。一種提高共用資源並發發性的方式是讓鎖定對象更有選擇性。盡量只鎖定需要修改的部分資料,而不是所有的資源。更理想的方式是,只對會修改的資料片進行精確的鎖定。任何時候,在給定的資源上,鎖定的資料量越少,則系統的並發程度越高,只要相互之間不發生衝突即可。但是,加鎖也需要消耗資源。鎖的各種操作,包括獲得鎖、檢查鎖和是否已經解除、釋放鎖等,都會增加系統的開銷。所謂鎖策略,就是在鎖的開銷和資料的安全性之間尋求平衡。
表鎖:管理鎖的開銷最小,同時允許的並發量也最小的鎖機制。MyIsam儲存引擎使用的鎖機制。當要寫入資料時,把整個表都鎖上,此時其他讀、寫動作一律等待。在MySql中,除了MyIsam儲存引擎使用這種鎖策略外,MySql本身也使用表鎖來執行某些特定動作,比如alter table.
另外,寫鎖比讀鎖有更高的優先順序,因此一個寫鎖可能會被插入到讀鎖隊列的前面。
行鎖:可以支援最大並發的鎖策略(同時也帶來了最大的鎖開銷)。InnoDB和Falcon兩張儲存引擎都採用這種策略。行級鎖只在儲存引擎層實現,而MySQL伺服器層沒有實現。伺服器層完全不瞭解儲存引擎中的鎖實現。
MySql是一種開放的架構,你可以實現自己的儲存引擎,並實現自己的鎖粒度策略,不像Oracle,你沒有機會改變鎖策略,Oracle採用的是行鎖。
1.3死結(Dead Lock)死結是指兩個或者多個事務在同一資源上相互佔用,並請求鎖定對方佔用的資源,從而導致惡性迴圈的假象。多個事務同時鎖定同一個資源時,也會產生死結。資料庫系統實現了各種死結檢測和死結逾時的機制,InnoDB目前處理死結的方法是,將持有最少行級獨佔鎖定的事務進行復原。 2.事務(Transaction)
2.1事務ACID原則從業務角度出發,對資料庫的一組操作要求保持4個特徵:
Atomicity(原子性):一個事務必須被視為一個不可分割的最小工作單元,整個事務中的所有操作要麼全部提交成功,要麼全部失敗復原,對於一個事務來說,不可能只執行其中的一部分操作,這就是事務的原子性。
Consistency(一致性):資料庫總是從一個一致性狀態轉換到另一個一致狀態。下面的銀行列子會說到。
Isolation(隔離性):通常來說,一個事務所做的修改在最終提交以前,對其他事務是不可見的。注意這裡的“通常來說”,後面的事務隔離級層級會說到。
Durability(持久性):一旦事務提交,則其所做的修改就會永久儲存到資料庫中。此時即使系統崩潰,修改的資料也不會丟失。(持久性的安全性與重新整理記錄層級也存在一定關係,不同的層級對應不同的資料安全層級。)
為了更好地理解ACID,以銀行賬戶轉賬為例:
1 START TRANSACTION;
2 SELECT balance FROM checking WHERE customer_id = 10233276;
3 UPDATE checking SET balance = balance - 200.00 WHERE customer_id = 10233276;
4 UPDATE savings SET balance = balance + 200.00 WHERE customer_id = 10233276;
5 COMMIT;
原子性:要麼完全提交(10233276的checking餘額減少200,savings 的餘額增加200),要麼完全復原(兩個表的餘額都不發生變化)
一致性:這個例子的一致性體現在 200元不會因為資料庫系統運行到第3行之後,第4行之前時崩潰而不翼而飛,因為事物還沒有提交。
隔離性:允許在一個事務中的動作陳述式會與其他事務的語句隔離開,比如事務A運行到第3行之後,第4行之前,此時事務B去查詢checking餘額時,它仍然能夠看到在事務A中被減去的200元(賬戶錢不變),因為事務A和B是彼此隔離的。在事務A提交之前,事務B觀察不到資料的改變。
持久性:這個很好理解。
事務跟鎖一樣都會需要大量工作,因此你可以根據你自己的需要來決定是否需要事務支援,從而選擇不同的儲存引擎。
2.2隔離等級(Isolation Level)
SQL標準定義了4類隔離等級,包括了一些具體規則,用來限定事務內外的哪些改變是可見的,哪些是不可見的。低層級的隔離級一般支援更高的並發處理,並擁有更低的系統開銷。
Read Uncommitted(未提交讀)
在該隔離等級,所有事務都可以看到其他未提交事務的執行結果。本隔離等級很少用於實際應用,因為它的效能也不比其他層級好多少。讀取未提交的資料,也被稱之為髒讀(Dirty Read)。
Read Committed(提交讀)
這是大多數資料庫系統的預設隔離等級(但不是MySQL預設的)。它滿足了隔離的簡單定義:一個事務只能看見已經提交事務所做的改變。這種隔離等級 也支援所謂的不可重複讀取(Nonrepeatable Read),因為同一事務的其他執行個體在該執行個體處理其間可能會有新的commit,所以同一select可能返回不同結果。
Repeatable Read(可重複讀)
這是MySQL的預設交易隔離等級,它確保同一事務的多個執行個體在並發讀取資料時,會看到同樣的資料行。不過理論上,這會導致另一個棘手的問題:幻讀 (Phantom Read)。簡單的說,幻讀指當使用者讀取某一範圍的資料行時,另一個事務又在該範圍插入入了新行,當使用者再讀取該範圍的資料行時,會發現有新的“幻影” 行。InnoDB和Falcon儲存引擎通過多版本並發控制(MVCC,Multiversion Concurrency Control)機制解決了該問題。
這裡有介紹MVCC策略:http://blog.csdn.net/xifeijian/article/details/45230053
Serializable(可序列化)
這是最高的隔離等級,它通過強制事務排序,使之不可能相互衝突,從而解決幻讀問題。簡言之,它是在每個讀的資料行上加上共用鎖定。在這個層級,可能導致大量的逾時現象和鎖競爭。
這四種隔離等級採取不同的鎖類型來實現,若讀取的是同一個資料的話,就容易發生問題。例如:
髒讀(Drity Read):某個事務已更新一份資料,另一個事務在此時讀取了同一份資料,由於某些原因,前一個RollBack了操作,則後一個事務所讀取的資料就會是不正確的。
不可重複讀取(Non-repeatable read):在一個事務的兩次查詢之中資料不一致,這可能是兩次查詢過程中間插入了一個事務更新的原有的資料。
幻讀(Phantom Read):在一個事務的兩次查詢中資料筆數不一致,例如有一個事務查詢了幾列(Row)資料,而另一個事務卻在此時插入了新的幾列資料,先前的事務在接下來的查詢中,就會發現有幾列資料是它先前所沒有的。
在MySQL中,實現了這四種隔離等級,分別有可能產生問題如下所示:
MySQL重點:《高效能MySQL》讀書筆記--索引:http://blog.csdn.net/xifeijian/article/details/20312557
《高效能MySQL》讀書筆記--鎖、事務、隔離等級 轉