以前參加過一個庫存系統(tǒng)，由于其業(yè)務復雜性，搞了很多個應用來支撐。這樣的話一份庫存數(shù)據(jù)就有可能同時有多個應用來修改庫存數(shù)據(jù)。
創(chuàng)新互聯(lián)公司是一家專注于網(wǎng)站建設、成都做網(wǎng)站和服務器托管的網(wǎng)絡公司，有著豐富的建站經(jīng)驗和案例。
比如說，有定時任務域xx.cron，和SystemA域和SystemB域這幾個JAVA應用，可能同時修改同一份庫存數(shù)據(jù)。如果不做協(xié)調(diào)的話，就會有臟數(shù)據(jù)出現(xiàn)。
對于跨JAVA進程的線程協(xié)調(diào)，可以借助外部環(huán)境，例如DB或者Redis。下文介紹一下如何使用DB來實現(xiàn)分布式鎖。
本文設計的分布式鎖的交互方式如下：
在使用synchronized關鍵字的時候，必須指定一個鎖對象。
進程內(nèi)的線程可以基于obj來實現(xiàn)同步。obj在這里可以理解為一個鎖對象。如果線程要進入synchronized代碼塊里，必須先持有obj對象上的鎖。這種鎖是JAVA里面的內(nèi)置鎖，創(chuàng)建的過程是線程安全的。那么借助DB，如何保證創(chuàng)建鎖的過程是線程安全的呢？
可以利用DB中的UNIQUE KEY特性，一旦出現(xiàn)了重復的key，由于UNIQUE KEY的唯一性，會拋出異常的。在JAVA里面，是 SQLIntegrityConstraintViolationException 異常。
transaction_id是事務Id，比如說，可以用
來組裝一個transaction_id，表示某倉庫某銷售模式下的某個條碼資源。不同條碼，當然就有不同的transaction_id。如果有兩個應用，拿著相同的transaction_id來創(chuàng)建鎖資源的時候，只能有一個應用創(chuàng)建成功。
在寫操作頻繁的業(yè)務系統(tǒng)中，通常會進行分庫，以降低單數(shù)據(jù)庫寫入的壓力，并提高寫操作的吞吐量。如果使用了分庫，那么業(yè)務數(shù)據(jù)自然也都分配到各個數(shù)據(jù)庫上了。
在這種水平切分的多數(shù)據(jù)庫上使用DB分布式鎖，可以自定義一個DataSouce列表。并暴露一個 getConnection(String transactionId) 方法，按照transactionId找到對應的Connection。
實現(xiàn)代碼如下：
首先編寫一個initDataSourceList方法，并利用Spring的PostConstruct注解初始化一個DataSource 列表。相關的DB配置從db.properties讀取。
DataSource使用阿里的DruidDataSource。
接著最重要的一個實現(xiàn)getConnection(String transactionId)方法。實現(xiàn)原理很簡單，獲取transactionId的hashcode，并對DataSource的長度取模即可。
連接池列表設計好后，就可以實現(xiàn)往distributed_lock表插入數(shù)據(jù)了。
接下來利用DB的 select for update 特性來鎖住線程。當多個線程根據(jù)相同的transactionId并發(fā)同時操作 select for update 的時候，只有一個線程能成功，其他線程都block住，直到 select for update 成功的線程使用commit操作后，block住的所有線程的其中一個線程才能開始干活。
我們在上面的DistributedLock類中創(chuàng)建一個lock方法。
當線程執(zhí)行完任務后，必須手動的執(zhí)行解鎖操作，之前被鎖住的線程才能繼續(xù)干活。在我們上面的實現(xiàn)中，其實就是獲取到當時 select for update 成功的線程對應的Connection，并實行commit操作即可。
那么如何獲取到呢？我們可以利用ThreadLocal。首先在DistributedLock類中定義
每次調(diào)用lock方法的時候，把Connection放置到ThreadLocal里面。我們修改lock方法。
這樣子，當獲取到Connection后，將其設置到ThreadLocal中，如果lock方法出現(xiàn)異常，則將其從ThreadLocal中移除掉。
有了這幾步后，我們可以來實現(xiàn)解鎖操作了。我們在DistributedLock添加一個unlock方法。
畢竟是利用DB來實現(xiàn)分布式鎖，對DB還是造成一定的壓力。當時考慮使用DB做分布式的一個重要原因是，我們的應用是后端應用，平時流量不大的，反而關鍵的是要保證庫存數(shù)據(jù)的正確性。對于像前端庫存系統(tǒng)，比如添加購物車占用庫存等操作，最好別使用DB來實現(xiàn)分布式鎖了。
如果想鎖住多份數(shù)據(jù)該怎么實現(xiàn)？比如說，某個庫存操作，既要修改物理庫存，又要修改虛擬庫存，想鎖住物理庫存的同時，又鎖住虛擬庫存。其實也不是很難，參考lock方法，寫一個multiLock方法，提供多個transactionId的入?yún)?，for循環(huán)處理就可以了。這個后續(xù)有時間再補上。
如果兩個程序都向表中寫數(shù)據(jù)顯然會造成很大的麻煩，甚至會有意外情況發(fā)生。如果表正由一個程序?qū)懭?，同時進行讀取的另一個程序也會產(chǎn)生混亂的結(jié)果。
鎖定表的方法
防止客戶機的請求互相干擾或者服務器與維護程序相互干擾的方法主要有多種。如果你關閉數(shù)據(jù)庫，就可以保證服務器
和myisamchk和isamchk之間沒有交互作用。但是停止服務器的運行并不是一個好注意，因為這樣做會使得沒有故障的數(shù)據(jù)庫和表也不可用。本節(jié)主
要討論的過程，是避免服務器和myisamchk或isamchk之間的交互作用。實現(xiàn)這種功能的方法是對表進行鎖定。
服務器由兩種表的鎖定方法：
1.內(nèi)部鎖定
內(nèi)部鎖定可以避免客戶機的請求相互干擾——例如，避免客戶機的SELECT查詢被另一個客戶機的UPDATE查詢所干擾。也可以利用內(nèi)部鎖定機制防止服務器在利用myisamchk或isamchk檢查或修復表時對表的訪問。
語法：鎖定表：LOCK TABLES tbl_name {READ | WRITE},[ tbl_name {READ | WRITE},…]
解鎖表：UNLOCK TABLES
LOCK TABLES為當前線程鎖定表。UNLOCK TABLES釋放被當前線程持有的任何鎖。當線程發(fā)出另外一個LOCK TABLES時，或當服務器的連接被關閉時，當前線程鎖定的所有表自動被解鎖。
如果一個線程獲得在一個表上的一個READ鎖，該線程(和所有其他線程)只能從表中讀。如果一個線程獲得一個表上的一個WRITE鎖，那么只有持鎖的線程READ或WRITE表，其他線程被阻止。
每個線程等待(沒有超時)直到它獲得它請求的所有鎖。
WRITE鎖通常比READ鎖有更高的優(yōu)先級，以確保更改盡快被處理。這意味著，如果一個線程獲得READ鎖，并且然后另外一個線程請求一個WRITE鎖, 隨后的READ鎖請求將等待直到WRITE線程得到了鎖并且釋放了它。
顯然對于檢查，你只需要獲得讀鎖。再者鐘情跨下，只能讀取表，但不能修改它，因此他也允許其它客戶機讀取表。對于修復，你必須獲得些所以防止任何客戶機在你對表進行操作時修改它。
2.外部鎖定
服務器還可以使用外部鎖定(文件級鎖)來防止其它程序在服務器使用表時修改文件。通常，在表的檢查操作中服務器
將外部鎖定與myisamchk或isamchk作合使用。但是，外部鎖定在某些系統(tǒng)中是禁用的，因為他不能可靠的進行工作。對運行myisamchk或
isamchk所選擇的過程取決于服務器是否能使用外部鎖定。如果不使用，則必修使用內(nèi)部鎖定協(xié)議。
如果服務器用--skip-locking選項運行，則外部鎖定禁用。該選項在某些系統(tǒng)中是缺省的，如Linux?？梢酝ㄟ^運行mysqladmin variables命令確定服務器是否能夠使用外部鎖定。檢查skip_locking變量的值并按以下方法進行：◆如果skip_locking為off，則外部鎖定有效您可以繼續(xù)并運行人和一個實用程序來檢查表。服務器和實用程序?qū)⒑献鲗Ρ磉M行訪問。但是，運行任何
一個實用程序之前，應該使用mysqladmin flush-tables。為了修復表，應該使用表的修復鎖定協(xié)議。
◆如果skip_locaking為on，則禁用外部鎖定，所以在myisamchk或isamchk檢查修復表示服務器并不知道，最好關閉服務器。如果堅
持是服務器保持開啟狀態(tài)，月確保在您使用此表示沒有客戶機來訪問它。
鎖是計算機協(xié)調(diào)多個進程或線程并發(fā)訪問某一資源的機制，在數(shù)據(jù)庫中，除傳統(tǒng)的計算資源（CPU、RAM、I/O）爭用外，數(shù)據(jù)也是一種供許多用戶共享的資源，如何保證數(shù)據(jù)并發(fā)訪問的一致性，有效性是所有數(shù)據(jù)庫必須解決的一個問題，鎖沖突也是影響數(shù)據(jù)庫并發(fā)訪問性能的一個重要因素，從這個角度來說，鎖對數(shù)據(jù)庫而言是尤其重要，也更加復雜。MySQL中的鎖，按照鎖的粒度分為:1、全局鎖，就鎖定數(shù)據(jù)庫中的所有表。2、表級鎖，每次操作鎖住整張表。3、行級鎖，每次操作鎖住對應的行數(shù)據(jù)。
全局鎖就是對整個數(shù)據(jù)庫實例加鎖，加鎖后整個實例就處于只讀狀態(tài)，后續(xù)的DML的寫語句，DDL語句，已經(jīng)更新操作的事務提交語句都將阻塞。其典型的使用場景就是做全庫的邏輯備份，對所有的表進行鎖定，從而獲取一致性視圖，保證數(shù)據(jù)的完整性。但是對數(shù)據(jù)庫加全局鎖是有弊端的，如在主庫上備份，那么在備份期間都不能執(zhí)行更新，業(yè)務會受影響，第二如果是在從庫上備份，那么在備份期間從庫不能執(zhí)行主庫同步過來的二進制日志，會導致主從延遲。
解決辦法是在innodb引擎中，備份時加上--single-transaction參數(shù)來完成不加鎖的一致性數(shù)據(jù)備份。
添加全局鎖: flush tables with read lock; 解鎖 unlock tables。
表級鎖,每次操作會鎖住整張表.鎖定粒度大,發(fā)送鎖沖突的概率最高,并發(fā)讀最低,應用在myisam、innodb、BOB等存儲引擎中。表級鎖分為: 表鎖、元數(shù)據(jù)鎖(meta data lock, MDL)和意向鎖。
表鎖又分為: 表共享讀鎖 read lock、表獨占寫鎖write lock
語法: 1、加鎖 lock tables 表名 ... read/write
2、釋放鎖 unlock tables 或者關閉客戶端連接
注意: 讀鎖不會阻塞其它客戶端的讀，但是會阻塞其它客戶端的寫，寫鎖既會阻塞其它客戶端的讀，又會阻塞其它客戶端的寫。大家可以拿一張表來測試看看。
元數(shù)據(jù)鎖,在加鎖過程中是系統(tǒng)自動控制的，無需顯示使用，在訪問一張表的時候會自動加上，MDL鎖主要作用是維護表元數(shù)據(jù)的數(shù)據(jù)一致性，在表上有活動事務的時候，不可以對元數(shù)據(jù)進行寫入操作。為了避免DML和DDL沖突，保證讀寫的正確性。
在MySQL5.5中引入了MDL，當對一張表進行增刪改查的時候，加MDL讀鎖(共享)；當對表結(jié)構(gòu)進行變更操作時，加MDL寫鎖(排他).
查看元數(shù)據(jù)鎖:
select object_type,object_schema,object_name,lock_type,lock_duration from performance_schema_metadata_locks;
意向鎖，為了避免DML在執(zhí)行時，加的行鎖與表鎖的沖突，在innodb中引入了意向鎖，使得表鎖不用檢查每行數(shù)據(jù)是否加鎖，使用意向鎖來減少表鎖的檢查。意向鎖分為,意向共享鎖is由語句select ... lock in share mode添加。意向排他鎖ix,由insert，update，delete，select。。。for update 添加。
select object_schema,object_name,index_name,lock_type,lock_mode,lock_data from performance_schema.data_lock;
行級鎖，每次操作鎖住對應的行數(shù)據(jù)，鎖定粒度最小，發(fā)生鎖沖突的概率最高，并發(fā)讀最高，應用在innodb存儲引擎中。
innodb的數(shù)據(jù)是基于索引組織的，行鎖是通過對索引上的索引項加鎖來實現(xiàn)的，而不是對記錄加的鎖，對于行級鎖，主要分為以下三類:
1、行鎖或者叫record lock記錄鎖，鎖定單個行記錄的鎖，防止其他事物對次行進行update和delete操作，在RC,RR隔離級別下都支持。
2、間隙鎖Gap lock,鎖定索引記錄間隙(不含該記錄)，確保索引記錄間隙不變，防止其他事物在這個間隙進行insert操作，產(chǎn)生幻讀，在RR隔離級別下都支持。
3、臨鍵鎖Next-key-lock,行鎖和間隙鎖組合，同時鎖住數(shù)據(jù)，并鎖住數(shù)據(jù)前面的間隙Gap,在RR隔離級別下支持。
innodb實現(xiàn)了以下兩種類型的行鎖
1、共享鎖 S: 允許一個事務去讀一行，阻止其他事務獲得相同數(shù)據(jù)集的排他鎖。
2、排他鎖 X: 允許獲取排他鎖的事務更新數(shù)據(jù)，阻止其他事務獲得相同數(shù)據(jù)集的共享鎖和排他鎖。
insert 語句 排他鎖 自動添加的
update語句 排他鎖 自動添加
delete 語句 排他鎖 自動添加
select 正常查詢語句 不加鎖 。。。
select 。。。lock in share mode 共享鎖 需要手動在select 之后加lock in share mode
select 。。。for update 排他鎖 需要手動在select之后添加for update
默認情況下，innodb在repeatable read事務隔離級別運行，innodb使用next-key鎖進行搜索和索引掃描，以防止幻讀。
間隙鎖唯一目的是防止其它事務插入間隙，間隙鎖可以共存，一個事務采用的間隙鎖不會阻止另一個事務在同一間隙上采用的間隙鎖。
當多個用戶訪問同一份數(shù)據(jù)時，一個用戶在更改數(shù)據(jù)的過程中，可能有其他用戶同時發(fā)起更改請求，為保證數(shù)據(jù)庫記錄的更新從一個一致性狀態(tài)變?yōu)榱硗庖粋€一致性狀態(tài)，使用事務處理是非常必要的，事務具有以下四個特性：
MySQL 提供了多種事務型存儲引擎，如 InnoDB 和 BDB 等，而 MyISAM 不支持事務。為了支持事務，InnoDB 存儲引擎引入了與事務處理相關的 REDO 日志和 UNDO 日志，同時事務依賴于 MySQL 提供的鎖機制
事務執(zhí)行時需要將執(zhí)行的事務日志寫入日志文件，對應的文件為 REDO 日志。當每條 SQL 進行數(shù)據(jù)更新操作時，首先將 REDO 日志寫進日志緩沖區(qū)。當客戶端執(zhí)行 COMMIT 命令提交時，日志緩沖區(qū)的內(nèi)容將被刷新到磁盤，日志緩沖區(qū)的刷新方式或者時間間隔可以通過參數(shù) innodb_flush_log_at_trx_commit 控制
REDO 日志對應磁盤上的 ib_logifleN 文件，該文件默認為 5MB，建議設置為 512MB，以便容納較大的事務。MySQL 崩潰恢復時會重新執(zhí)行 REDO 日志的記錄，恢復最新數(shù)據(jù)，保證已提交事務的持久性
與 REDO 日志相反，UNDO 日志主要用于事務異常時的數(shù)據(jù)回滾，具體內(nèi)容就是記錄數(shù)據(jù)被修改前的信息到 UNDO 緩沖區(qū)，然后在合適的時間將內(nèi)容刷新到磁盤
假如由于系統(tǒng)錯誤或者 rollback 操作而導致事務回滾，可以根據(jù) undo 日志回滾到?jīng)]修改前的狀態(tài)，保證未提交事務的原子性
與 REDO 日志不同的是，磁盤上不存在單獨的 UNDO 日志文件，所有的 UNDO 日志均存在表空間對應的 .ibd 數(shù)據(jù)文件中，即使 MySQL 服務啟動了獨立表空間
在 MySQL 中，可以使用 BEGIN 開始事務，使用 COMMIT 結(jié)束事務，中間可以使用 ROLLBACK 回滾事務。MySQL 通過 SET AUTOCOMMIT、START TRANSACTION、COMMIT 和 ROLLBACK 等語句支持本地事務
MySQL 定義了四種隔離級別，指定事務中哪些數(shù)據(jù)改變其他事務可見、哪些數(shù)據(jù)該表其他事務不可見。低級別的隔離級別可以支持更高的并發(fā)處理，同時占用的系統(tǒng)資源更少
InnoDB 系統(tǒng)級事務隔離級別可以使用以下語句設置：
查看系統(tǒng)級事務隔離級別：
InnoDB 會話級事務隔離級別可以使用以下語句設置：
查看會話級事務隔離級別：
在該隔離級別，所有事務都可以看到其他未提交事務的執(zhí)行結(jié)果。讀取未提交的數(shù)據(jù)稱為臟讀（Dirty Read），即是：首先開啟 A 和 B 兩個事務，在 B 事務更新但未提交之前，A 事務讀取到了更新后的數(shù)據(jù)，但由于 B 事務回滾，導致 A 事務出現(xiàn)了臟讀現(xiàn)象
所有事務只能看見已經(jīng)提交事務所做的改變，此級別可以解決臟讀，但也會導致不可重復讀（Nonrepeatable Read）：首先開啟 A 和 B 兩個事務，A事務讀取了 B 事務的數(shù)據(jù)，在 B 事務更新并提交后，A 事務又讀取到了更新后的數(shù)據(jù)，此時就出現(xiàn)了同一 A 事務中的查詢出現(xiàn)了不同的查詢結(jié)果
MySQL 默認的事務隔離級別，能確保同一事務的多個實例在并發(fā)讀取數(shù)據(jù)時看到同樣的數(shù)據(jù)行，理論上會導致一個問題，幻讀（Phontom Read）。例如，第一個事務對一個表中的數(shù)據(jù)做了修改，這種修改會涉及表中的全部數(shù)據(jù)行，同時第二個事務也修改這個表中的數(shù)據(jù)，這次的修改是向表中插入一行新數(shù)據(jù)，此時就會發(fā)生操作第一個事務的用戶發(fā)現(xiàn)表中還有沒有修改的數(shù)據(jù)行
InnoDB 通過多版本并發(fā)控制機制（MVCC）解決了該問題：InnoDB 通過為每個數(shù)據(jù)行增加兩個隱含值的方式來實現(xiàn)，這兩個隱含值記錄了行的創(chuàng)建時間、過期時間以及每一行存儲時間發(fā)生時的系統(tǒng)版本號，每個查詢根據(jù)事務的版本號來查詢結(jié)果
通過強制事務排序，使其不可能相互沖突，從而解決幻讀問題。簡而言之，就是在每個讀的數(shù)據(jù)行上加上共享鎖實現(xiàn)，這個級別會導致大量的超時現(xiàn)象和鎖競爭，一般不推薦使用
為了解決數(shù)據(jù)庫并發(fā)控制問題，如走到同一時刻客戶端對同一張表做更新或者查詢操作，需要對并發(fā)操作進行控制，因此產(chǎn)生了鎖
共享鎖的粒度是行或者元組（多個行），一個事務獲取了共享鎖以后，可以對鎖定范圍內(nèi)的數(shù)據(jù)執(zhí)行讀操作
排他鎖的粒度與共享鎖相同，一個事務獲取排他鎖以后，可以對鎖定范圍內(nèi)的數(shù)據(jù)執(zhí)行寫操作
有兩個事務 A 和 B，如果事務 A 獲取了一個元組的共享鎖，事務 B 還可以立即獲取這個元組的共享鎖，但不能獲取這個元組的排他鎖，必須等到事務 A 釋放共享鎖之后。如果事務 A 獲取了一個元組的排他鎖，事務 B 不能立即獲取這個元組的共享鎖，也不能立即獲取這個元組的排他鎖，必須等到 A 釋放排他鎖之后
意向鎖是一種表鎖，鎖定的粒度是整張表，分為意向共享鎖和意向排他鎖。意向共享鎖表示一個事務有意對數(shù)據(jù)上共享鎖或者排他鎖。有意表示事務想執(zhí)行操作但還沒真正執(zhí)行
鎖的粒度主要分為表鎖和行鎖
表鎖的開銷最小，同時允許的并發(fā)量也是最小。MyISAM 存儲引擎使用該鎖機制。當要寫入數(shù)據(jù)時，整個表記錄被鎖，此時其他讀/寫動作一律等待。一些特定的動作，如 ALTER TABLE 執(zhí)行時使用的也是表鎖
行鎖可以支持最大的并發(fā)，InnoDB 存儲引擎使用該鎖機制。如果要支持并發(fā)讀/寫，建議采用 InnoDB 存儲引擎
mysql鎖分為共享鎖和排他鎖，也叫做讀鎖和寫鎖。
讀鎖是共享的，可以通過lock in share mode實現(xiàn)，這時候只能讀不能寫。
寫鎖是排他的，它會阻塞其他的寫鎖和讀鎖。從顆粒度來區(qū)分，可以分為表鎖和?鎖兩種。
表鎖會鎖定整張表并且阻塞其他?戶對該表的所有讀寫操作，?如alter修改表結(jié)構(gòu)的時候會鎖表。
?鎖?可以分為樂觀鎖和悲觀鎖，悲觀鎖可以通過for update實現(xiàn)，樂觀鎖則通過版本號實現(xiàn)。
加鎖情況與死鎖原因分析
為方便大家復現(xiàn)，完整表結(jié)構(gòu)和數(shù)據(jù)如下：
CREATE TABLE `t3` (
`c1` int(11) NOT NULL AUTO_INCREMENT,
`c2` int(11) DEFAULT NULL,
PRIMARY KEY (`c1`),
UNIQUE KEY `c2` (`c2`)
) ENGINE=InnoDB
insert into t3 values(1,1),(15,15),(20,20);
在 session1 執(zhí)行 commit 的瞬間，我們會看到 session2、session3 的其中一個報死鎖。這個死鎖是這樣產(chǎn)生的：
1.?session1 執(zhí)行 delete ?會在唯一索引 c2 的 c2 = 15 這一記錄上加 X lock（也就是在MySQL 內(nèi)部觀測到的：X Lock but not gap）；
2.?session2 和 session3 在執(zhí)行 insert 的時候，由于唯一約束檢測發(fā)生唯一沖突，會加 S Next-Key Lock，即對 (1,15] 這個區(qū)間加鎖包括間隙，并且被 seesion1 的 X Lock 阻塞，進入等待；
3.?session1 在執(zhí)行 commit 后，會釋放 X Lock，session2 和 session3 都獲得 S Next-Key Lock；
4.?session2 和 session3 繼續(xù)執(zhí)行插入操作，這個時候 INSERT INTENTION LOCK（插入意向鎖）出現(xiàn)了，并且由于插入意向鎖會被 gap 鎖阻塞，所以 session2 和 session3 互相等待，造成死鎖。
死鎖日志如下：
請點擊輸入圖片描述
INSERT INTENTION LOCK
在之前的死鎖分析第四點，如果不分析插入意向鎖，也是會造成死鎖的，因為插入最終還是要對記錄加 X Lock 的，session2 和 session3 還是會互相阻塞互相等待。
但是插入意向鎖是客觀存在的，我們可以在官方手冊中查到，不可忽略：
Prior to inserting the row, a type of gap lock called an insert intention gap lock is set. This lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the same position within the gap.
插入意向鎖其實是一種特殊的 gap lock，但是它不會阻塞其他鎖。假設存在值為 4 和 7 的索引記錄，嘗試插入值 5 和 6 的兩個事務在獲取插入行上的排它鎖之前使用插入意向鎖鎖定間隙，即在（4，7）上加 gap lock，但是這兩個事務不會互相沖突等待。
當插入一條記錄時，會去檢查當前插入位置的下一條記錄上是否存在鎖對象，如果下一條記錄上存在鎖對象，就需要判斷該鎖對象是否鎖住了 gap。如果 gap 被鎖住了，則插入意向鎖與之沖突，進入等待狀態(tài)（插入意向鎖之間并不互斥）。總結(jié)一下這把鎖的屬性：
1. 它不會阻塞其他任何鎖；
2. 它本身僅會被 gap lock 阻塞。
在學習 MySQL 過程中，一般只有在它被阻塞的時候才能觀察到，所以這也是它常常被忽略的原因吧...
GAP LOCK
在此例中，另外一個重要的點就是 gap lock，通常情況下我們說到 gap lock 都只會聯(lián)想到 REPEATABLE-READ 隔離級別利用其解決幻讀。但實際上在 READ-COMMITTED 隔離級別，也會存在 gap lock ，只發(fā)生在：唯一約束檢查到有唯一沖突的時候，會加 S Next-key Lock，即對記錄以及與和上一條記錄之間的間隙加共享鎖。
通過下面這個例子就能驗證：
請點擊輸入圖片描述
這里 session1 插入數(shù)據(jù)遇到唯一沖突，雖然報錯，但是對 (15,20] 加的 S Next-Key Lock 并不會馬上釋放，所以 session2 被阻塞。另外一種情況就是本文開始的例子，當 session2 插入遇到唯一沖突但是因為被 X Lock 阻塞，并不會立刻報錯 “Duplicate key”，但是依然要等待獲取 S Next-Key Lock 。
有個困惑很久的疑問：出現(xiàn)唯一沖突需要加 S Next-Key Lock 是事實，但是加鎖的意義是什么？還是說是通過 S Next-Key Lock 來實現(xiàn)的唯一約束檢查，但是這樣意味著在插入沒有遇到唯一沖突的時候，這個鎖會立刻釋放，這不符合二階段鎖原則。這點希望能與大家一起討論得到好的解釋。
如果是在 REPEATABLE-READ，除以上所說的唯一約束沖突外，gap lock 的存在是這樣的：
普通索引（非唯一索引）的S/X Lock，都帶 gap 屬性，會鎖住記錄以及前1條記錄到后1條記錄的左閉右開區(qū)間，比如有[4,6,8]記錄，delete 6，則會鎖住[4,8）整個區(qū)間。
對于 gap lock，相信 DBA 們的心情是一樣一樣的，所以我的建議是：
1. 在絕大部分的業(yè)務場景下，都可以把 MySQL 的隔離界別設置為 READ-COMMITTED；
2. 在業(yè)務方便控制字段值唯一的情況下，盡量減少表中唯一索引的數(shù)量。
鎖沖突矩陣
前面我們說的 GAP LOCK 其實是鎖的屬性，另外我們知道 InnoDB 常規(guī)鎖模式有：S 和 X，即共享鎖和排他鎖。鎖模式和鎖屬性是可以隨意組合的，組合之后的沖突矩陣如下，這對我們分析死鎖很有幫助：
請點擊輸入圖片描述
重慶分公司
重慶分公司
