MySQL中的鎖機制,按粒度分為行級鎖,頁級鎖,表級鎖，其中按用法還分為共享鎖和排他鎖. **行級鎖** 行級鎖是Mysql中鎖定粒度最細的一種鎖，表示只針對當前操作的行進行加鎖。 行級鎖能大大減少數(shù)據(jù)庫操作的沖突。其加鎖粒度最小，但加鎖的開銷也最大。行級鎖分為共享鎖和排他鎖. 特點 開銷大，加鎖慢；會出現(xiàn)死鎖；鎖定粒度最小，發(fā)生鎖沖突的概率最低，并發(fā)度也最高。 用法 共享鎖(s 鎖 讀鎖) **表級鎖** 表級鎖是MySQL中鎖定粒度最大的一種鎖，表示對當前操作的整張表加鎖，它實現(xiàn)簡單，資源消耗較少，被大部分MySQL引擎支持。 最常使用的MYISAM與INNODB都支持表級鎖定。表級鎖定分為共享鎖和排他鎖. 特點 開銷小，加鎖快；不會出現(xiàn)死鎖；鎖定粒度大，發(fā)出鎖沖突的概率最高，并發(fā)度最低。 用法 共享鎖(s 鎖 讀鎖) **頁級鎖** 頁級鎖是MySQL中鎖定粒度介于行級鎖和表級鎖中間的一種鎖。 表級鎖速度快，但沖突多，行級沖突少，但速度慢。所以取了折衷的頁級，一次鎖定相鄰的一組記錄。BDB支持頁級鎖 特點 開銷和加鎖時間界于表鎖和行鎖之間；會出現(xiàn)死鎖；鎖定粒度界于表鎖和行鎖之間，并發(fā)度一般。 樂觀鎖和悲觀鎖的思想 在數(shù)據(jù)庫的鎖機制中介紹過，數(shù)據(jù)庫管理系統(tǒng)（DBMS）中的并發(fā)控制的任務是確保在多個事務同時存取數(shù)據(jù)庫中同一數(shù)據(jù)時不破壞事務的隔離性和統(tǒng)一性以及數(shù)據(jù)庫的統(tǒng)一性。 樂觀并發(fā)控制(樂觀鎖)和悲觀并發(fā)控制（悲觀鎖）是并發(fā)控制主要采用的技術手段。 無論是悲觀鎖還是樂觀鎖，都是人們定義出來的概念，可以認為是一種思想。 其實不僅僅是關系型數(shù)據(jù)庫系統(tǒng)中有樂觀鎖和悲觀鎖的概念，像memcache、hibernate、tair等都有類似的概念。 針對于不同的業(yè)務場景，應該選用不同的并發(fā)控制方式。所以，不要把樂觀并發(fā)控制和悲觀并發(fā)控制狹義的理解為DBMS中的概念，更不要把他們和數(shù)據(jù)中提供的鎖機制（行鎖、表鎖、排他鎖、共享鎖）混為一談。其實，在DBMS中，悲觀鎖正是利用數(shù)據(jù)庫本身提供的鎖機制來實現(xiàn)的。 **悲觀鎖** 在關系數(shù)據(jù)庫管理系統(tǒng)里，悲觀并發(fā)控制（又名“悲觀鎖”，Pessimistic Concurrency Control，縮寫“PCC”）是一種并發(fā)控制的方法。它可以阻止一個事務以影響其他用戶的方式來修改數(shù)據(jù)。 如果一個事務執(zhí)行的操作都某行數(shù)據(jù)應用了鎖，那只有當這個事務把鎖釋放，其他事務才能夠執(zhí)行與該鎖沖突的操作。 悲觀并發(fā)控制主要用于數(shù)據(jù)爭用激烈的環(huán)境，以及發(fā)生并發(fā)沖突時使用鎖保護數(shù)據(jù)的成本要低于回滾事務的成本的環(huán)境中。 悲觀鎖，正如其名，它指的是對數(shù)據(jù)被外界（包括本系統(tǒng)當前的其他事務，以及來自外部系統(tǒng)的事務處理）修改持保守態(tài)度(悲觀) 因此，在整個數(shù)據(jù)處理過程中，將數(shù)據(jù)處于鎖定狀態(tài)。 悲觀鎖的實現(xiàn)，往往依靠數(shù)據(jù)庫提供的鎖機制 （也只有數(shù)據(jù)庫層提供的鎖機制才能真正保證數(shù)據(jù)訪問的排他性，否則，即使在本系統(tǒng)中實現(xiàn)了加鎖機制，也無法保證外部系統(tǒng)不會修改數(shù)據(jù)） 在數(shù)據(jù)庫中，悲觀鎖的流程如下： 在對任意記錄進行修改前，先嘗試為該記錄加上排他鎖（exclusive locking） 如果加鎖失敗，說明該記錄正在被修改，那么當前查詢可能要等待或者拋出異常。具體響應方式由開發(fā)者根據(jù)實際需要決定。 如果成功加鎖，那么就可以對記錄做修改，事務完成后就會解鎖了。 其間如果有其他對該記錄做修改或加排他鎖的操作，都會等待我們解鎖或直接拋出異常。 MySQL InnoDB中使用悲觀鎖 要使用悲觀鎖，我們必須關閉mysql數(shù)據(jù)庫的自動提交屬性，因為MySQL默認使用autocommit模式 也就是說，當你執(zhí)行一個更新操作后，MySQL會立刻將結果進行提交。set autocommit=0; 優(yōu)點與不足 悲觀并發(fā)控制實際上是“先取鎖再訪問”的保守策略，為數(shù)據(jù)處理的安全提供了保證。 但是在效率方面，處理加鎖的機制會讓數(shù)據(jù)庫產(chǎn)生額外的開銷，還有增加產(chǎn)生死鎖的機會； 另外，在只讀型事務處理中由于不會產(chǎn)生沖突，也沒必要使用鎖，這樣做只能增加系統(tǒng)負載； 還有會降低了并行性，一個事務如果鎖定了某行數(shù)據(jù)，其他事務就必須等待該事務處理完才可以處理那行數(shù) **樂觀鎖** 在關系數(shù)據(jù)庫管理系統(tǒng)里，樂觀并發(fā)控制（又名“樂觀鎖”，Optimistic Concurrency Control，縮寫“OCC”）是一種并發(fā)控制的方法。 它假設多用戶并發(fā)的事務在處理時不會彼此互相影響，各事務能夠在不產(chǎn)生鎖的情況下處理各自影響的那部分數(shù)據(jù)。 在提交數(shù)據(jù)更新之前，每個事務會先檢查在該事務讀取數(shù)據(jù)后，有沒有其他事務又修改了該數(shù)據(jù)。如果其他事務有更新的話，正在提交的事務會進行回滾。 樂觀事務控制最早是由孔祥重（H.T.Kung）教授提出。 樂觀鎖（ Optimistic Locking ） 相對悲觀鎖而言，樂觀鎖假設認為數(shù)據(jù)一般情況下不會造成沖突 所以在數(shù)據(jù)進行提交更新的時候，才會正式對數(shù)據(jù)的沖突與否進行檢測 如果發(fā)現(xiàn)沖突了，則讓返回用戶錯誤的信息，讓用戶決定如何去做。 相對于悲觀鎖，在對數(shù)據(jù)庫進行處理的時候，樂觀鎖并不會使用數(shù)據(jù)庫提供的鎖機制。一般的實現(xiàn)樂觀鎖的方式就是記錄數(shù)據(jù)版本。 數(shù)據(jù)版本,為數(shù)據(jù)增加的一個版本標識。當讀取數(shù)據(jù)時，將版本標識的值一同讀出，數(shù)據(jù)每更新一次，同時對版本標識進行更新。 當我們提交更新的時候，判斷數(shù)據(jù)庫表對應記錄的當前版本信息與第一次取出來的版本標識進行比對，如果數(shù)據(jù)庫表當前版本號與第一次取出來的版本標識值相等，則予以更新，否則認為是過期數(shù)據(jù)。 實現(xiàn)數(shù)據(jù)版本有兩種方式，第一種是使用版本號，第二種是使用時間戳。 樂觀鎖使用CAS（Compare And Swep）操作保證數(shù)據(jù)一致性 使用版本號實現(xiàn)樂觀鎖 使用版本號時，可以在數(shù)據(jù)初始化時指定一個版本號，每次對數(shù)據(jù)的更新操作都對版本號執(zhí)行+1操作。并判斷當前版本號是不是該數(shù)據(jù)的最新的版本號。 樂觀并發(fā)控制相信事務之間的數(shù)據(jù)競爭(data race)的概率是比較小的，因此盡可能直接做下去，直到提交的時候才去鎖定，所以不會產(chǎn)生任何鎖和死鎖。 但如果直接簡單這么做，還是有可能會遇到不可預期的結果，例如兩個事務都讀取了數(shù)據(jù)庫的某一行，經(jīng)過修改以后寫回數(shù)據(jù)庫，這時就遇到了問題。 MySQL常用存儲引擎的鎖機制 MyISAM和MEMORY采用表級鎖(table-level locking) BDB采用頁面鎖(page-level locking)或表級鎖，默認為頁面鎖 InnoDB支持行級鎖(row-level locking)和表級鎖,默認為行級鎖 Innodb中的行鎖與表鎖 InnoDB行鎖是通過給索引上的索引項加鎖來實現(xiàn)的，這一點MySQL與Oracle不同，后者是通過在數(shù)據(jù)塊中對相應數(shù)據(jù)行加鎖來實現(xiàn)的。 InnoDB這種行鎖實現(xiàn)特點意味著：只有通過索引條件檢索數(shù)據(jù)，InnoDB才使用行級鎖，否則，InnoDB將使用表鎖！ 在實際應用中，要特別注意InnoDB行鎖的這一特性，不然的話，可能導致大量的鎖沖突，從而影響并發(fā)性能。 在不通過索引條件查詢的時候,InnoDB 確實使用的是表鎖,而不是行鎖。 由于 MySQL 的行鎖是針對索引加的鎖,不是針對記錄加的鎖,所以雖然是訪問不同行的記錄,但是如果是使用相同的索引鍵,是會出現(xiàn)鎖沖突的。應用設計的時候要注意這一點。 當表有多個索引的時候,不同的事務可以使用不同的索引鎖定不同的行,另外,不論 是使用主鍵索引、唯一索引或普通索引,InnoDB 都會使用行鎖來對數(shù)據(jù)加鎖。 即便在條件中使用了索引字段,但是否使用索引來檢索數(shù)據(jù)是由 MySQL 通過判斷不同 執(zhí)行計劃的代價來決定的,如果 MySQL 認為全表掃效率更高,比如對一些很小的表,它就不會使用索引,這種情況下 InnoDB 將使用表鎖,而不是行鎖。因此,在分析鎖沖突時, 別忘了檢查 SQL 的執(zhí)行計劃,以確認是否真正使用了索引。 **行級鎖與死鎖** MyISAM中是不會產(chǎn)生死鎖的，因為MyISAM總是一次性獲得所需的全部鎖，要么全部滿足，要么全部等待。 而在InnoDB中，鎖是逐步獲得的，就造成了死鎖的可能。 在MySQL中，行級鎖并不是直接鎖記錄，而是鎖索引。 索引分為主鍵索引和非主鍵索引兩種，如果一條sql語句操作了主鍵索引，MySQL就會鎖定這條主鍵索引；如果一條語句操作了非主鍵索引，MySQL會先鎖定該非主鍵索引，再鎖定相關的主鍵索引。 在UPDATE、DELETE操作時，MySQL不僅鎖定WHERE條件掃描過的所有索引記錄，而且會鎖定相鄰的鍵值，即所謂的next-key locking。 當兩個事務同時執(zhí)行，一個鎖住了主鍵索引，在等待其他相關索引。另一個鎖定了非主鍵索引，在等待主鍵索引。這樣就會發(fā)生死鎖。 發(fā)生死鎖后，InnoDB一般都可以檢測到，并使一個事務釋放鎖回退，另一個獲取鎖完成事務。 避免死鎖，這里只介紹常見的三種： 如果不同程序會并發(fā)存取多個表，盡量約定以相同的順序訪問表，可以大大降低死鎖機會 在同一個事務中，盡可能做到一次鎖定所需要的所有資源，減少死鎖產(chǎn)生概率 對于非常容易產(chǎn)生死鎖的業(yè)務部分，可以嘗試使用升級鎖定顆粒度，通過表級鎖定來減少死鎖產(chǎn)生的概率 >【云棲號在線課堂】每天都有產(chǎn)品技術專家分享！ > 課程地址：https://yqh.aliyun.com/zhibo > 立即加入社群，與專家面對面，及時了解課程最新動態(tài)！ > 【云棲號在線課堂 社群】https://c.tb.cn/F3.Z8gvnK 原文發(fā)布時間：2020-07-10 本文作者：suveng 本文來自：“”，了解相關信息可以關注“”