數據庫的鎖機制(悲觀鎖/樂觀鎖)

在數據庫的鎖機制中介紹過，數據庫管理系統（DBMS）中的併發控制的任務是確保在多個事務同時存取數據庫中同一數據時不破壞事務的隔離性和統一性以及數據庫的統一性。

樂觀併發控制(樂觀鎖)和悲觀併發控制（悲觀鎖）是併發控制主要採用的技術手段。

無論是悲觀鎖還是樂觀鎖，都是人們定義出來的概念，可以認爲是一種思想。其實不僅僅是關係型數據庫系統中有樂觀鎖和悲觀鎖的概念，像memcache、hibernate、tair等都有類似的概念。

針對於不同的業務場景，應該選用不同的併發控制方式。所以，不要把樂觀併發控制和悲觀併發控制狹義的理解爲DBMS中的概念，更不要把他們和數據中提供的鎖機制（行鎖、表鎖、排他鎖、共享鎖）混爲一談。其實，在DBMS中，悲觀鎖正是利用數據庫本身提供的鎖機制來實現的。

下面來分別學習一下悲觀鎖和樂觀鎖。

悲觀鎖

在關係數據庫管理系統裏，悲觀併發控制（又名“悲觀鎖”，Pessimistic Concurrency Control，縮寫“PCC”）是一種併發控制的方法。它可以阻止一個事務以影響其他用戶的方式來修改數據。如果一個事務執行的操作都某行數據應用了鎖，那只有當這個事務把鎖釋放，其他事務才能夠執行與該鎖衝突的操作。 
悲觀併發控制主要用於數據爭用激烈的環境，以及發生併發衝突時使用鎖保護數據的成本要低於回滾事務的成本的環境中。

悲觀鎖，正如其名，它指的是對數據被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）修改持保守態度(悲觀)，因此，在整個數據處理過程中，將數據處於鎖定狀態。 悲觀鎖的實現，往往依靠數據庫提供的鎖機制 （也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據）

在數據庫中，悲觀鎖的流程如下：

在對任意記錄進行修改前，先嚐試爲該記錄加上排他鎖（exclusive locking）。

如果加鎖失敗，說明該記錄正在被修改，那麼當前查詢可能要等待或者拋出異常。 具體響應方式由開發者根據實際需要決定。

如果成功加鎖，那麼就可以對記錄做修改，事務完成後就會解鎖了。

其間如果有其他對該記錄做修改或加排他鎖的操作，都會等待我們解鎖或直接拋出異常。

MySQL InnoDB中使用悲觀鎖

要使用悲觀鎖，我們必須關閉mysql數據庫的自動提交屬性，因爲MySQL默認使用autocommit模式，也就是說，當你執行一個更新操作後，MySQL會立刻將結果進行提交。set autocommit=0;

//0.開始事務
begin;/begin work;/start transaction; (三者選一就可以)
//1.查詢出商品信息
select status from t_goods where id=1 for update;
//2.根據商品信息生成訂單
insert into t_orders (id,goods_id) values (null,1);
//3.修改商品status爲2
update t_goods set status=2;
//4.提交事務
commit;/commit work;

• • 1　　//0.開始事務
  • 2　　begin;/begin work;/start transaction; (三者選一就可以)
  • 3　　//1.查詢出商品信息
  • 4　　select status from t_goods where id=1 for update;
  • 5　　//2.根據商品信息生成訂單
  • 6　　insert into t_orders (id,goods_id) values (null,1);
  • 7　　//3.修改商品status爲2
  • 8　　update t_goods set status=2;
  • 9　　//4.提交事務
  • 10　　commit;/commit work;

上面的查詢語句中，我們使用了select…for update的方式，這樣就通過開啓排他鎖的方式實現了悲觀鎖。此時在t_goods表中，id爲1的 那條數據就被我們鎖定了，其它的事務必須等本次事務提交之後才能執行。這樣我們可以保證當前的數據不會被其它事務修改。

上面我們提到，使用select…for update會把數據給鎖住，不過我們需要注意一些鎖的級別，MySQL InnoDB默認行級鎖。行級鎖都是基於索引的，如果一條SQL語句用不到索引是不會使用行級鎖的，會使用表級鎖把整張表鎖住，這點需要注意。

優點與不足

悲觀併發控制實際上是“先取鎖再訪問”的保守策略，爲數據處理的安全提供了保證。但是在效率方面，處理加鎖的機制會讓數據庫產生額外的開銷，還有增加產生死鎖的機會；另外，在只讀型事務處理中由於不會產生衝突，也沒必要使用鎖，這樣做只能增加系統負載；還有會降低了並行性，一個事務如果鎖定了某行數據，其他事務就必須等待該事務處理完纔可以處理那行數

樂觀鎖

在關係數據庫管理系統裏，樂觀併發控制（又名“樂觀鎖”，Optimistic Concurrency Control，縮寫“OCC”）是一種併發控制的方法。它假設多用戶併發的事務在處理時不會彼此互相影響，各事務能夠在不產生鎖的情況下處理各自影響的那部分數據。在提交數據更新之前，每個事務會先檢查在該事務讀取數據後，有沒有其他事務又修改了該數據。如果其他事務有更新的話，正在提交的事務會進行回滾。樂觀事務控制最早是由孔祥重（H.T.Kung）教授提出。

樂觀鎖（ Optimistic Locking ） 相對悲觀鎖而言，樂觀鎖假設認爲數據一般情況下不會造成衝突，所以在數據進行提交更新的時候，纔會正式對數據的衝突與否進行檢測，如果發現衝突了，則讓返回用戶錯誤的信息，讓用戶決定如何去做。

相對於悲觀鎖，在對數據庫進行處理的時候，樂觀鎖並不會使用數據庫提供的鎖機制。一般的實現樂觀鎖的方式就是記錄數據版本。

數據版本,爲數據增加的一個版本標識。當讀取數據時，將版本標識的值一同讀出，數據每更新一次，同時對版本標識進行更新。當我們提交更新的時候，判斷數據庫表對應記錄的當前版本信息與第一次取出來的版本標識進行比對，如果數據庫表當前版本號與第一次取出來的版本標識值相等，則予以更新，否則認爲是過期數據。

實現數據版本有兩種方式，第一種是使用版本號，第二種是使用時間戳。

使用版本號實現樂觀鎖

使用版本號時，可以在數據初始化時指定一個版本號，每次對數據的更新操作都對版本號執行+1操作。並判斷當前版本號是不是該數據的最新的版本號。

1.查詢出商品信息

select (status,status,version) from t_goods where id=#{id}
2.根據商品信息生成訂單
3.修改商品status爲2
update t_goods 
set status=2,version=version+1
where id=#{id} and version=#{version};

• • 1　　select (status,status,version) from t_goods where id=#{id}
  • 2　　根據商品信息生成訂單
  • 3　　修改商品status爲2
  • 4　　update t_goods
  • 5　　set status=2,version=version+1
  • 6　　where id=#{id} and version=#{version};

優點與不足

樂觀併發控制相信事務之間的數據競爭(data race)的概率是比較小的，因此儘可能直接做下去，直到提交的時候纔去鎖定，所以不會產生任何鎖和死鎖。但如果直接簡單這麼做，還是有可能會遇到不可預期的結果，例如兩個事務都讀取了數據庫的某一行，經過修改以後寫回數據庫，這時就遇到了問題。

併發控制

在計算機科學，特別是程序設計、操作系統、多處理機和數據庫等領域，併發控制（Concurrency control）是確保及時糾正由併發操作導致的錯誤的一種機制。

數據庫管理系統（DBMS）中的併發控制的任務是確保在多個事務同時存取數據庫中同一數據時不破壞事務的隔離性和統一性以及數據庫的統一性。下面舉例說明併發操作帶來的數據不一致性問題：

現有兩處火車票售票點，同時讀取某一趟列車車票數據庫中車票餘額爲 X。兩處售票點同時賣出一張車票，同時修改餘額爲 X -1寫回數據庫，這樣就造成了實際賣出兩張火車票而數據庫中的記錄卻只少了一張。 產生這種情況的原因是因爲兩個事務讀入同一數據並同時修改，其中一個事務提交的結果破壞了另一個事務提交的結果，導致其數據的修改被丟失，破壞了事務的隔離性。併發控制要解決的就是這類問題。

封鎖、時間戳、樂觀併發控制(樂觀鎖)和悲觀併發控制（悲觀鎖）是併發控制主要採用的技術手段。

鎖

當併發事務同時訪問一個資源時，有可能導致數據不一致，因此需要一種機制來將數據訪問順序化，以保證數據庫數據的一致性。鎖就是其中的一種機制。

在計算機科學中，鎖是在執行多線程時用於強行限制資源訪問的同步機制，即用於在併發控制中保證對互斥要求的滿足。

鎖的分類(oracle)

一、按操作劃分，可分爲DML鎖、DDL鎖

二、按鎖的粒度劃分，可分爲表級鎖、行級鎖、頁級鎖（mysql）

三、按鎖級別劃分，可分爲共享鎖、排他鎖

四、按加鎖方式劃分，可分爲自動鎖、顯示鎖

五、按使用方式劃分，可分爲樂觀鎖、悲觀鎖

DML鎖（data locks，數據鎖），用於保護數據的完整性，其中包括行級鎖(Row Locks (TX鎖))、表級鎖(table lock(TM鎖))。 DDL鎖（dictionary locks，數據字典鎖），用於保護數據庫對象的結構，如表、索引等的結構定義。其中包排他DDL鎖（Exclusive DDL lock）、共享DDL鎖（Share DDL lock）、可中斷解析鎖（Breakable parse locks）

MySQL中的行級鎖,表級鎖,頁級鎖

在計算機科學中，鎖是在執行多線程時用於強行限制資源訪問的同步機制，即用於在併發控制中保證對互斥要求的滿足。

行級鎖

行級鎖是Mysql中鎖定粒度最細的一種鎖，表示只針對當前操作的行進行加鎖。行級鎖能大大減少數據庫操作的衝突。其加鎖粒度最小，但加鎖的開銷也最大。行級鎖分爲共享鎖 和 排他鎖。

特點

開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的概率最低，併發度也最高。

表級鎖

表級鎖是MySQL中鎖定粒度最大的一種鎖，表示對當前操作的整張表加鎖，它實現簡單，資源消耗較少，被大部分MySQL引擎支持。最常使用的MYISAM與INNODB都支持表級鎖定。表級鎖定分爲表共享讀鎖（共享鎖）與表獨佔寫鎖（排他鎖）。

特點

開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發出鎖衝突的概率最高，併發度最低。

頁級鎖

頁級鎖是MySQL中鎖定粒度介於行級鎖和表級鎖中間的一種鎖。表級鎖速度快，但衝突多，行級衝突少，但速度慢。所以取了折衷的頁級，一次鎖定相鄰的一組記錄。BDB支持頁級鎖

特點

開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，併發度一般

MySQL常用存儲引擎的鎖機制

MyISAM和MEMORY採用表級鎖(table-level locking)

BDB採用頁面鎖(page-level locking)或表級鎖，默認爲頁面鎖

InnoDB支持行級鎖(row-level locking)和表級鎖,默認爲行級鎖

Innodb中的行鎖與表鎖

前面提到過，在Innodb引擎中既支持行鎖也支持表鎖，那麼什麼時候會鎖住整張表，什麼時候或只鎖住一行呢？

InnoDB行鎖是通過給索引上的索引項加鎖來實現的，這一點MySQL與Oracle不同，後者是通過在數據塊中對相應數據行加鎖來實現的。InnoDB這種行鎖實現特點意味着：只有通過索引條件檢索數據，InnoDB才使用行級鎖，否則，InnoDB將使用表鎖！

在實際應用中，要特別注意InnoDB行鎖的這一特性，不然的話，可能導致大量的鎖衝突，從而影響併發性能。

行級鎖都是基於索引的，如果一條SQL語句用不到索引是不會使用行級鎖的，會使用表級鎖。行級鎖的缺點是：由於需要請求大量的鎖資源，所以速度慢，內存消耗大。

行級鎖與死鎖

MyISAM中是不會產生死鎖的，因爲MyISAM總是一次性獲得所需的全部鎖，要麼全部滿足，要麼全部等待。而在InnoDB中，鎖是逐步獲得的，就造成了死鎖的可能。

在MySQL中，行級鎖並不是直接鎖記錄，而是鎖索引。索引分爲主鍵索引和非主鍵索引兩種，如果一條sql語句操作了主鍵索引，MySQL就會鎖定這條主鍵索引；如果一條語句操作了非主鍵索引，MySQL會先鎖定該非主鍵索引，再鎖定相關的主鍵索引。 在UPDATE、DELETE操作時，MySQL不僅鎖定WHERE條件掃描過的所有索引記錄，而且會鎖定相鄰的鍵值，即所謂的next-key locking。

當兩個事務同時執行，一個鎖住了主鍵索引，在等待其他相關索引。另一個鎖定了非主鍵索引，在等待主鍵索引。這樣就會發生死鎖。

發生死鎖後，InnoDB一般都可以檢測到，並使一個事務釋放鎖回退，另一個獲取鎖完成事務。

---

有多種方法可以避免死鎖，這裏只介紹常見的三種

1、如果不同程序會併發存取多個表，儘量約定以相同的順序訪問表，可以大大降低死鎖機會。

2、在同一個事務中，儘可能做到一次鎖定所需要的所有資源，減少死鎖產生概率；

3、對於非常容易產生死鎖的業務部分，可以嘗試使用升級鎖定顆粒度，通過表級鎖定來減少死鎖產生的概率；

MySQL中的共享鎖與排他鎖

共享鎖(Share Lock)

共享鎖又稱讀鎖，是讀取操作創建的鎖。其他用戶可以併發讀取數據，但任何事務都不能對數據進行修改（獲取數據上的排他鎖），直到已釋放所有共享鎖。

如果事務T對數據A加上共享鎖後，則其他事務只能對A再加共享鎖，不能加排他鎖。獲准共享鎖的事務只能讀數據，不能修改數據。

用法

SELECT ... LOCK IN SHARE MODE;

在查詢語句後面增加LOCK IN SHARE MODE，Mysql會對查詢結果中的每行都加共享鎖，當沒有其他線程對查詢結果集中的任何一行使用排他鎖時，可以成功申請共享鎖，否則會被阻塞。其他線程也可以讀取使用了共享鎖的表，而且這些線程讀取的是同一個版本的數據。

排他鎖（eXclusive Lock）

排他鎖又稱寫鎖，如果事務T對數據A加上排他鎖後，則其他事務不能再對A加任任何類型的封鎖。獲准排他鎖的事務既能讀數據，又能修改數據。

用法

SELECT ... FOR UPDATE;

在查詢語句後面增加FOR UPDATE，Mysql會對查詢結果中的每行都加排他鎖，當沒有其他線程對查詢結果集中的任何一行使用排他鎖時，可以成功申請排他鎖，否則會被阻塞。

意向鎖

InnoDB還有兩個表鎖：

意向共享鎖（IS）：表示事務準備給數據行加入共享鎖，也就是說一個數據行加共享鎖前必須先取得該表的IS鎖

意向排他鎖（IX）：類似上面，表示事務準備給數據行加入排他鎖，說明事務在一個數據行加排他鎖前必須先取得該表的IX鎖。

意向鎖是InnoDB自動加的，不需要用戶干預。

對於insert、update、delete，InnoDB會自動給涉及的數據加排他鎖（X）；對於一般的Select語句，InnoDB不會加任何鎖，事務可以通過以下語句給顯示加共享鎖或排他鎖。

共享鎖：SELECT ... LOCK IN SHARE MODE;

排他鎖：SELECT ... FOR UPDATE;

樂觀鎖和悲觀鎖

樂觀併發控制(樂觀鎖)和悲觀併發控制（悲觀鎖）是併發控制主要採用的技術手段。

無論是悲觀鎖還是樂觀鎖，都是人們定義出來的概念，可以認爲是一種思想。其實不僅僅是關係型數據庫系統中有樂觀鎖和悲觀鎖的概念，像memcache、hibernate、tair等都有類似的概念。

針對於不同的業務場景，應該選用不同的併發控制方式。所以，不要把樂觀併發控制和悲觀併發控制狹義的理解爲DBMS中的概念，更不要把他們和數據中提供的鎖機制（行鎖、表鎖、排他鎖、共享鎖）混爲一談。其實，在DBMS中，悲觀鎖正是利用數據庫本身提供的鎖機制來實現的。

下面來分別學習一下悲觀鎖和樂觀鎖。

悲觀鎖

在關係數據庫管理系統裏，悲觀併發控制（又名“悲觀鎖”，Pessimistic Concurrency Control，縮寫“PCC”）是一種併發控制的方法。它可以阻止一個事務以影響其他用戶的方式來修改數據。如果一個事務執行的操作都某行數據應用了鎖，那只有當這個事務把鎖釋放，其他事務才能夠執行與該鎖衝突的操作。
悲觀併發控制主要用於數據爭用激烈的環境，以及發生併發衝突時使用鎖保護數據的成本要低於回滾事務的成本的環境中。

悲觀鎖，正如其名，它指的是對數據被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）修改持保守態度(悲觀)，因此，在整個數據處理過程中，將數據處於鎖定狀態。 悲觀鎖的實現，往往依靠數據庫提供的鎖機制 （也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據）

在數據庫中，悲觀鎖的流程如下：

在對任意記錄進行修改前，先嚐試爲該記錄加上排他鎖（exclusive locking）。

如果加鎖失敗，說明該記錄正在被修改，那麼當前查詢可能要等待或者拋出異常。 具體響應方式由開發者根據實際需要決定。

如果成功加鎖，那麼就可以對記錄做修改，事務完成後就會解鎖了。

其間如果有其他對該記錄做修改或加排他鎖的操作，都會等待我們解鎖或直接拋出異常。

MySQL InnoDB中使用悲觀鎖

要使用悲觀鎖，我們必須關閉mysql數據庫的自動提交屬性，因爲MySQL默認使用autocommit模式，也就是說，當你執行一個更新操作後，MySQL會立刻將結果進行提交。set autocommit=0;

//0.開始事務
begin;/begin work;/start transaction; (三者選一就可以)
//1.查詢出商品信息
select status from t_goods where id=1 for update;
//2.根據商品信息生成訂單
insert into t_orders (id,goods_id) values (null,1);
//3.修改商品status爲2
update t_goods set status=2;
//4.提交事務
commit;/commit work;

上面的查詢語句中，我們使用了select…for update的方式，這樣就通過開啓排他鎖的方式實現了悲觀鎖。此時在t_goods表中，id爲1的 那條數據就被我們鎖定了，其它的事務必須等本次事務提交之後才能執行。這樣我們可以保證當前的數據不會被其它事務修改。

上面我們提到，使用select…for update會把數據給鎖住，不過我們需要注意一些鎖的級別，MySQL InnoDB默認行級鎖。行級鎖都是基於索引的，如果一條SQL語句用不到索引是不會使用行級鎖的，會使用表級鎖把整張表鎖住，這點需要注意。

優點與不足

悲觀併發控制實際上是“先取鎖再訪問”的保守策略，爲數據處理的安全提供了保證。但是在效率方面，處理加鎖的機制會讓數據庫產生額外的開銷，還有增加產生死鎖的機會；另外，在只讀型事務處理中由於不會產生衝突，也沒必要使用鎖，這樣做只能增加系統負載；還有會降低了並行性，一個事務如果鎖定了某行數據，其他事務就必須等待該事務處理完纔可以處理那行數

樂觀鎖

在關係數據庫管理系統裏，樂觀併發控制（又名“樂觀鎖”，Optimistic Concurrency Control，縮寫“OCC”）是一種併發控制的方法。它假設多用戶併發的事務在處理時不會彼此互相影響，各事務能夠在不產生鎖的情況下處理各自影響的那部分數據。在提交數據更新之前，每個事務會先檢查在該事務讀取數據後，有沒有其他事務又修改了該數據。如果其他事務有更新的話，正在提交的事務會進行回滾。樂觀事務控制最早是由孔祥重（H.T.Kung）教授提出。

樂觀鎖（ Optimistic Locking ） 相對悲觀鎖而言，樂觀鎖假設認爲數據一般情況下不會造成衝突，所以在數據進行提交更新的時候，纔會正式對數據的衝突與否進行檢測，如果發現衝突了，則讓返回用戶錯誤的信息，讓用戶決定如何去做。

相對於悲觀鎖，在對數據庫進行處理的時候，樂觀鎖並不會使用數據庫提供的鎖機制。一般的實現樂觀鎖的方式就是記錄數據版本。

數據版本,爲數據增加的一個版本標識。當讀取數據時，將版本標識的值一同讀出，數據每更新一次，同時對版本標識進行更新。當我們提交更新的時候，判斷數據庫表對應記錄的當前版本信息與第一次取出來的版本標識進行比對，如果數據庫表當前版本號與第一次取出來的版本標識值相等，則予以更新，否則認爲是過期數據。

實現數據版本有兩種方式，第一種是使用版本號，第二種是使用時間戳。

使用版本號實現樂觀鎖

使用版本號時，可以在數據初始化時指定一個版本號，每次對數據的更新操作都對版本號執行+1操作。並判斷當前版本號是不是該數據的最新的版本號。

1.查詢出商品信息
select (status,status,version) from t_goods where id=#{id}
2.根據商品信息生成訂單
3.修改商品status爲2
update t_goods 
set status=2,version=version+1
where id=#{id} and version=#{version};

優點與不足

樂觀併發控制相信事務之間的數據競爭(data race)的概率是比較小的，因此儘可能直接做下去，直到提交的時候纔去鎖定，所以不會產生任何鎖和死鎖。但如果直接簡單這麼做，還是有可能會遇到不可預期的結果，例如兩個事務都讀取了數據庫的某一行，經過修改以後寫回數據庫，這時就遇到了問題。