MySQL中的鎖機(jī)制,按粒度分為行級(jí)鎖,頁(yè)級(jí)鎖,表級(jí)鎖，其中按用法還分為共享鎖和排他鎖.

行級(jí)鎖

行級(jí)鎖是Mysql中鎖定粒度最細(xì)的一種鎖，表示只針對(duì)當(dāng)前操作的行進(jìn)行加鎖。

行級(jí)鎖能大大減少數(shù)據(jù)庫(kù)操作的沖突。其加鎖粒度最小，但加鎖的開(kāi)銷也最大。行級(jí)鎖分為共享鎖和排他鎖.

特點(diǎn)

開(kāi)銷大，加鎖慢；會(huì)出現(xiàn)死鎖；鎖定粒度最小，發(fā)生鎖沖突的概率最低，并發(fā)度也最高。

用法

共享鎖(s 鎖 讀鎖)

用法：

排他鎖(x 鎖 寫鎖 )

用法：

表級(jí)鎖

表級(jí)鎖是MySQL中鎖定粒度最大的一種鎖，表示對(duì)當(dāng)前操作的整張表加鎖，它實(shí)現(xiàn)簡(jiǎn)單，資源消耗較少，被大部分MySQL引擎支持。

最常使用的MYISAM與INNODB都支持表級(jí)鎖定。表級(jí)鎖定分為共享鎖和排他鎖.

特點(diǎn)

開(kāi)銷小，加鎖快；不會(huì)出現(xiàn)死鎖；鎖定粒度大，發(fā)出鎖沖突的概率最高，并發(fā)度最低。

用法

共享鎖(s 鎖 讀鎖)

用法：

排他鎖(x 鎖 寫鎖 )

用法：

頁(yè)級(jí)鎖

頁(yè)級(jí)鎖是MySQL中鎖定粒度介于行級(jí)鎖和表級(jí)鎖中間的一種鎖。

表級(jí)鎖速度快，但沖突多，行級(jí)沖突少，但速度慢。所以取了折衷的頁(yè)級(jí)，一次鎖定相鄰的一組記錄。BDB支持頁(yè)級(jí)鎖

特點(diǎn)

開(kāi)銷和加鎖時(shí)間界于表鎖和行鎖之間；會(huì)出現(xiàn)死鎖；鎖定粒度界于表鎖和行鎖之間，并發(fā)度一般。

樂(lè)觀鎖和悲觀鎖的思想

在數(shù)據(jù)庫(kù)的鎖機(jī)制中介紹過(guò)，數(shù)據(jù)庫(kù)管理系統(tǒng)（DBMS）中的并發(fā)控制的任務(wù)是確保在多個(gè)事務(wù)同時(shí)存取數(shù)據(jù)庫(kù)中同一數(shù)據(jù)時(shí)不破壞事務(wù)的隔離性和統(tǒng)一性以及數(shù)據(jù)庫(kù)的統(tǒng)一性。

樂(lè)觀并發(fā)控制(樂(lè)觀鎖)和悲觀并發(fā)控制（悲觀鎖）是并發(fā)控制主要采用的技術(shù)手段。

無(wú)論是悲觀鎖還是樂(lè)觀鎖，都是人們定義出來(lái)的概念，可以認(rèn)為是一種思想。

其實(shí)不僅僅是關(guān)系型數(shù)據(jù)庫(kù)系統(tǒng)中有樂(lè)觀鎖和悲觀鎖的概念，像memcache、hibernate、tair等都有類似的概念。

針對(duì)于不同的業(yè)務(wù)場(chǎng)景，應(yīng)該選用不同的并發(fā)控制方式。所以，不要把樂(lè)觀并發(fā)控制和悲觀并發(fā)控制狹義的理解為DBMS中的概念，更不要把他們和數(shù)據(jù)中提供的鎖機(jī)制（行鎖、表鎖、排他鎖、共享鎖）混為一談。其實(shí)，在DBMS中，悲觀鎖正是利用數(shù)據(jù)庫(kù)本身提供的鎖機(jī)制來(lái)實(shí)現(xiàn)的。

悲觀鎖

在關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng)里，悲觀并發(fā)控制（又名“悲觀鎖”，Pessimistic Concurrency Control，縮寫“PCC”）是一種并發(fā)控制的方法。它可以阻止一個(gè)事務(wù)以影響其他用戶的方式來(lái)修改數(shù)據(jù)。

如果一個(gè)事務(wù)執(zhí)行的操作都某行數(shù)據(jù)應(yīng)用了鎖，那只有當(dāng)這個(gè)事務(wù)把鎖釋放，其他事務(wù)才能夠執(zhí)行與該鎖沖突的操作。

悲觀并發(fā)控制主要用于數(shù)據(jù)爭(zhēng)用激烈的環(huán)境，以及發(fā)生并發(fā)沖突時(shí)使用鎖保護(hù)數(shù)據(jù)的成本要低于回滾事務(wù)的成本的環(huán)境中。

悲觀鎖，正如其名，它指的是對(duì)數(shù)據(jù)被外界（包括本系統(tǒng)當(dāng)前的其他事務(wù)，以及來(lái)自外部系統(tǒng)的事務(wù)處理）修改持保守態(tài)度(悲觀)

因此，在整個(gè)數(shù)據(jù)處理過(guò)程中，將數(shù)據(jù)處于鎖定狀態(tài)。 

悲觀鎖的實(shí)現(xiàn)，往往依靠數(shù)據(jù)庫(kù)提供的鎖機(jī)制 （也只有數(shù)據(jù)庫(kù)層提供的鎖機(jī)制才能真正保證數(shù)據(jù)訪問(wèn)的排他性，否則，即使在本系統(tǒng)中實(shí)現(xiàn)了加鎖機(jī)制，也無(wú)法保證外部系統(tǒng)不會(huì)修改數(shù)據(jù)）

在數(shù)據(jù)庫(kù)中，悲觀鎖的流程如下：

在對(duì)任意記錄進(jìn)行修改前，先嘗試為該記錄加上排他鎖（exclusive locking）

如果加鎖失敗，說(shuō)明該記錄正在被修改，那么當(dāng)前查詢可能要等待或者拋出異常。具體響應(yīng)方式由開(kāi)發(fā)者根據(jù)實(shí)際需要決定。

如果成功加鎖，那么就可以對(duì)記錄做修改，事務(wù)完成后就會(huì)解鎖了。

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

MySQL InnoDB中使用悲觀鎖

要使用悲觀鎖，我們必須關(guān)閉mysql數(shù)據(jù)庫(kù)的自動(dòng)提交屬性，因?yàn)镸ySQL默認(rèn)使用autocommit模式

也就是說(shuō)，當(dāng)你執(zhí)行一個(gè)更新操作后，MySQL會(huì)立刻將結(jié)果進(jìn)行提交。set autocommit=0;

優(yōu)點(diǎn)與不足

悲觀并發(fā)控制實(shí)際上是“先取鎖再訪問(wèn)”的保守策略，為數(shù)據(jù)處理的安全提供了保證。

但是在效率方面，處理加鎖的機(jī)制會(huì)讓數(shù)據(jù)庫(kù)產(chǎn)生額外的開(kāi)銷，還有增加產(chǎn)生死鎖的機(jī)會(huì)；

另外，在只讀型事務(wù)處理中由于不會(huì)產(chǎn)生沖突，也沒(méi)必要使用鎖，這樣做只能增加系統(tǒng)負(fù)載；

還有會(huì)降低了并行性，一個(gè)事務(wù)如果鎖定了某行數(shù)據(jù)，其他事務(wù)就必須等待該事務(wù)處理完才可以處理那行數(shù)

樂(lè)觀鎖

在關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng)里，樂(lè)觀并發(fā)控制（又名“樂(lè)觀鎖”，Optimistic Concurrency Control，縮寫“OCC”）是一種并發(fā)控制的方法。

它假設(shè)多用戶并發(fā)的事務(wù)在處理時(shí)不會(huì)彼此互相影響，各事務(wù)能夠在不產(chǎn)生鎖的情況下處理各自影響的那部分?jǐn)?shù)據(jù)。

在提交數(shù)據(jù)更新之前，每個(gè)事務(wù)會(huì)先檢查在該事務(wù)讀取數(shù)據(jù)后，有沒(méi)有其他事務(wù)又修改了該數(shù)據(jù)。如果其他事務(wù)有更新的話，正在提交的事務(wù)會(huì)進(jìn)行回滾。

樂(lè)觀事務(wù)控制最早是由孔祥重（H.T.Kung）教授提出。

樂(lè)觀鎖（ Optimistic Locking ） 相對(duì)悲觀鎖而言，樂(lè)觀鎖假設(shè)認(rèn)為數(shù)據(jù)一般情況下不會(huì)造成沖突

所以在數(shù)據(jù)進(jìn)行提交更新的時(shí)候，才會(huì)正式對(duì)數(shù)據(jù)的沖突與否進(jìn)行檢測(cè)

如果發(fā)現(xiàn)沖突了，則讓返回用戶錯(cuò)誤的信息，讓用戶決定如何去做。

相對(duì)于悲觀鎖，在對(duì)數(shù)據(jù)庫(kù)進(jìn)行處理的時(shí)候，樂(lè)觀鎖并不會(huì)使用數(shù)據(jù)庫(kù)提供的鎖機(jī)制。一般的實(shí)現(xiàn)樂(lè)觀鎖的方式就是記錄數(shù)據(jù)版本。

數(shù)據(jù)版本,為數(shù)據(jù)增加的一個(gè)版本標(biāo)識(shí)。當(dāng)讀取數(shù)據(jù)時(shí)，將版本標(biāo)識(shí)的值一同讀出，數(shù)據(jù)每更新一次，同時(shí)對(duì)版本標(biāo)識(shí)進(jìn)行更新。

當(dāng)我們提交更新的時(shí)候，判斷數(shù)據(jù)庫(kù)表對(duì)應(yīng)記錄的當(dāng)前版本信息與第一次取出來(lái)的版本標(biāo)識(shí)進(jìn)行比對(duì)，如果數(shù)據(jù)庫(kù)表當(dāng)前版本號(hào)與第一次取出來(lái)的版本標(biāo)識(shí)值相等，則予以更新，否則認(rèn)為是過(guò)期數(shù)據(jù)。

實(shí)現(xiàn)數(shù)據(jù)版本有兩種方式，第一種是使用版本號(hào)，第二種是使用時(shí)間戳。

樂(lè)觀鎖使用CAS（Compare And Swep）操作保證數(shù)據(jù)一致性

使用版本號(hào)實(shí)現(xiàn)樂(lè)觀鎖

使用版本號(hào)時(shí)，可以在數(shù)據(jù)初始化時(shí)指定一個(gè)版本號(hào)，每次對(duì)數(shù)據(jù)的更新操作都對(duì)版本號(hào)執(zhí)行+1操作。并判斷當(dāng)前版本號(hào)是不是該數(shù)據(jù)的最新的版本號(hào)。

樂(lè)觀并發(fā)控制相信事務(wù)之間的數(shù)據(jù)競(jìng)爭(zhēng)(data race)的概率是比較小的，因此盡可能直接做下去，直到提交的時(shí)候才去鎖定，所以不會(huì)產(chǎn)生任何鎖和死鎖。

但如果直接簡(jiǎn)單這么做，還是有可能會(huì)遇到不可預(yù)期的結(jié)果，例如兩個(gè)事務(wù)都讀取了數(shù)據(jù)庫(kù)的某一行，經(jīng)過(guò)修改以后寫回?cái)?shù)據(jù)庫(kù)，這時(shí)就遇到了問(wèn)題。

MySQL常用存儲(chǔ)引擎的鎖機(jī)制

MyISAM和MEMORY采用表級(jí)鎖(table-level locking)

BDB采用頁(yè)面鎖(page-level locking)或表級(jí)鎖，默認(rèn)為頁(yè)面鎖

InnoDB支持行級(jí)鎖(row-level locking)和表級(jí)鎖,默認(rèn)為行級(jí)鎖

Innodb中的行鎖與表鎖

InnoDB行鎖是通過(guò)給索引上的索引項(xiàng)加鎖來(lái)實(shí)現(xiàn)的，這一點(diǎn)MySQL與Oracle不同，后者是通過(guò)在數(shù)據(jù)塊中對(duì)相應(yīng)數(shù)據(jù)行加鎖來(lái)實(shí)現(xiàn)的。

InnoDB這種行鎖實(shí)現(xiàn)特點(diǎn)意味著：只有通過(guò)索引條件檢索數(shù)據(jù)，InnoDB才使用行級(jí)鎖，否則，InnoDB將使用表鎖！

在實(shí)際應(yīng)用中，要特別注意InnoDB行鎖的這一特性，不然的話，可能導(dǎo)致大量的鎖沖突，從而影響并發(fā)性能。

• 在不通過(guò)索引條件查詢的時(shí)候,InnoDB 確實(shí)使用的是表鎖,而不是行鎖。

• 由于 MySQL 的行鎖是針對(duì)索引加的鎖,不是針對(duì)記錄加的鎖,所以雖然是訪問(wèn)不同行的記錄,但是如果是使用相同的索引鍵,是會(huì)出現(xiàn)鎖沖突的。應(yīng)用設(shè)計(jì)的時(shí)候要注意這一點(diǎn)。

• 當(dāng)表有多個(gè)索引的時(shí)候,不同的事務(wù)可以使用不同的索引鎖定不同的行,另外,不論 是使用主鍵索引、唯一索引或普通索引,InnoDB 都會(huì)使用行鎖來(lái)對(duì)數(shù)據(jù)加鎖。

• 即便在條件中使用了索引字段,但是否使用索引來(lái)檢索數(shù)據(jù)是由 MySQL 通過(guò)判斷不同 執(zhí)行計(jì)劃的代價(jià)來(lái)決定的,如果 MySQL 認(rèn)為全表掃效率更高,比如對(duì)一些很小的表,它就不會(huì)使用索引,這種情況下 InnoDB 將使用表鎖,而不是行鎖。因此,在分析鎖沖突時(shí), 別忘了檢查 SQL 的執(zhí)行計(jì)劃,以確認(rèn)是否真正使用了索引。

行級(jí)鎖與死鎖

MyISAM中是不會(huì)產(chǎn)生死鎖的，因?yàn)镸yISAM總是一次性獲得所需的全部鎖，要么全部滿足，要么全部等待。

而在InnoDB中，鎖是逐步獲得的，就造成了死鎖的可能。

在MySQL中，行級(jí)鎖并不是直接鎖記錄，而是鎖索引。

索引分為主鍵索引和非主鍵索引兩種，如果一條sql語(yǔ)句操作了主鍵索引，MySQL就會(huì)鎖定這條主鍵索引；如果一條語(yǔ)句操作了非主鍵索引，MySQL會(huì)先鎖定該非主鍵索引，再鎖定相關(guān)的主鍵索引。

在UPDATE、DELETE操作時(shí)，MySQL不僅鎖定WHERE條件掃描過(guò)的所有索引記錄，而且會(huì)鎖定相鄰的鍵值，即所謂的next-key locking。

當(dāng)兩個(gè)事務(wù)同時(shí)執(zhí)行，一個(gè)鎖住了主鍵索引，在等待其他相關(guān)索引。另一個(gè)鎖定了非主鍵索引，在等待主鍵索引。這樣就會(huì)發(fā)生死鎖。

發(fā)生死鎖后，InnoDB一般都可以檢測(cè)到，并使一個(gè)事務(wù)釋放鎖回退，另一個(gè)獲取鎖完成事務(wù)。

避免死鎖，這里只介紹常見(jiàn)的三種：

1. 如果不同程序會(huì)并發(fā)存取多個(gè)表，盡量約定以相同的順序訪問(wèn)表，可以大大降低死鎖機(jī)會(huì)

2. 在同一個(gè)事務(wù)中，盡可能做到一次鎖定所需要的所有資源，減少死鎖產(chǎn)生概率

3. 對(duì)于非常容易產(chǎn)生死鎖的業(yè)務(wù)部分，可以嘗試使用升級(jí)鎖定顆粒度，通過(guò)表級(jí)鎖定來(lái)減少死鎖產(chǎn)生的概率

END

本文版權(quán)歸作者所有,來(lái)源：

https://blog.csdn.net/qq_37933685/article/details/80717515

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：

長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝