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

8gw234 9年前發布 | 15K 次閱讀 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;
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中，實現了這四種隔離級別，分別有可能產生問題如下所示：

來自：

本文由用戶 8gw234 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1430041323045.html

MySQL 數據庫服務器