程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MySQL綜合教程 >> 《高性能MySQL》讀書筆記--鎖、事務、隔離級別

《高性能MySQL》讀書筆記--鎖、事務、隔離級別

編輯:MySQL綜合教程

《高性能MySQL》讀書筆記--鎖、事務、隔離級別


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;

原子性:要麼完全提交(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中,實現了這四種隔離級別,分別有可能產生問題如下所示:

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved