加鎖情況與死鎖原因分析
創(chuàng)新互聯(lián)建站擁有10余年成都網(wǎng)站建設工作經(jīng)驗,為各大企業(yè)提供成都做網(wǎng)站、成都網(wǎng)站設計服務，對于網(wǎng)頁設計、PC網(wǎng)站建設（電腦版網(wǎng)站建設）、成都app開發(fā)、wap網(wǎng)站建設（手機版網(wǎng)站建設）、程序開發(fā)、網(wǎng)站優(yōu)化（SEO優(yōu)化）、微網(wǎng)站、主機域名等，憑借多年來在互聯(lián)網(wǎng)的打拼，我們在互聯(lián)網(wǎng)網(wǎng)站建設行業(yè)積累了很多網(wǎng)站制作、網(wǎng)站設計、網(wǎng)絡營銷經(jīng)驗，集策劃、開發(fā)、設計、營銷、管理等網(wǎng)站化運作于一體，具備承接各種規(guī)模類型的網(wǎng)站建設項目的能力。
為方便大家復現(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)（插入意向鎖之間并不互斥）?？偨Y(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，即共享鎖和排他鎖。鎖模式和鎖屬性是可以隨意組合的，組合之后的沖突矩陣如下，這對我們分析死鎖很有幫助：
請點擊輸入圖片描述
以下五種方法可以快速定位全局鎖的位置，僅供參考。
方法1：利用 metadata_locks 視圖
此方法僅適用于 MySQL 5.7 以上版本，該版本 performance_schema 新增了 metadata_locks，如果上鎖前啟用了元數(shù)據(jù)鎖的探針（默認是未啟用的），可以比較容易的定位全局鎖會話。
方法2：利用 events_statements_history 視圖此方法適用于 MySQL 5.6 以上版本，啟用 performance_schema.eventsstatements_history（5.6 默認未啟用，5.7 默認啟用），該表會 SQL 歷史記錄執(zhí)行，如果請求太多，會自動清理早期的信息，有可能將上鎖會話的信息清理掉。
方法3：利用 gdb 工具如果上述兩種都用不了或者沒來得及啟用，可以嘗試第三種方法。利用 gdb 找到所有線程信息，查看每個線程中持有全局鎖對象，輸出對應的會話 ID，為了便于快速定位，我寫成了腳本形式。也可以使用 gdb 交互模式，但 attach mysql 進程后 mysql 會完全 hang 住，讀請求也會受到影響，不建議使用交互模式。
方法4：show processlist
如果備份程序使用的特定用戶執(zhí)行備份，如果是 root 用戶備份，那 time 值越大的是持鎖會話的概率越大，如果業(yè)務也用 root 訪問，重點是 state 和 info 為空的，這里有個小技巧可以快速篩選，篩選后嘗試 kill 對應 ID，再觀察是否還有 wait global read lock 狀態(tài)的會話。
方法5：重啟試試！
1、在mysql數(shù)據(jù)庫中如何鎖定一行數(shù)據(jù)，保證不被其他的操作影響。
2、從對數(shù)據(jù)的操作類型分為讀鎖和寫鎖。從對數(shù)據(jù)操作的粒度來分：表鎖和行鎖。
3、現(xiàn)在我們建立一個表來演示數(shù)據(jù)庫的行鎖講解。
4、行鎖基本演示如下圖所示。
5、如果兩個會話操作的是不同的行，就不會互相阻塞了。
下面通過一個例子來說明
場景如下：
用戶賬戶有余額，當發(fā)生交易時，需要實時更新余額。這里如果發(fā)生并發(fā)問題，那么會造成用戶余額和實際交易的不一致，這對公司和客戶來說都是很危險的。
那么如何避免：
網(wǎng)上查了下，有以下兩種方法：
1、使用悲觀鎖
當需要變更余額時，通過代碼在事務中對當前需要更新的記錄設置for update行鎖，然后開始正常的查詢和更新操作
這樣，其他的事務只能等待該事務完成后方可操作
當然要特別注意，如果使用了Spring的事務注解，需要配置一下：
!-- (事務管理)transaction manager, use JtaTransactionManager for global tx --
bean id="transactionManager"
class="org.springframework.jdbc.datasource.DataSourceTransactionManager"
property name="dataSource" ref="dataSource" /
/bean
!-- 使用annotation定義事務 --
tx:annotation-driven transaction-manager="transactionManager" /
在指定代碼處添加事務注解
@Transactional
@Override
public boolean increaseBalanceByLock(Long userId, BigDecimal amount)
throws ValidateException {
long time = System.currentTimeMillis();
//獲取對記錄的鎖定
UserBalance balance = userBalanceDao.getLock(userId);
LOGGER.info("[lock] start. time: {}", time);
if (null == balance) {
throw new ValidateException(
ValidateErrorCode.ERRORCODE_BALANCE_NOTEXIST,
"user balance is not exist");
}
boolean result = userBalanceDao.increaseBalanceByLock(balance, amount);
long timeEnd = System.currentTimeMillis();
LOGGER.info("[lock] end. time: {}", timeEnd);
return result;
}
MyBatis中的鎖定方式，實際測試該方法確實可以有效控制，不過在大并發(fā)量的情況下，可能會有性能問題吧
select id="getLock" resultMap="BaseResultMap" parameterType="java.lang.Long"
![CDATA[
select * from user_balance where id=#{id,jdbcType=BIGINT} for update;
]]
/select
2、使用樂觀鎖
這個方法也同樣可以解決場景中描述的問題（我認為比較適合并不頻繁的操作）：
設計表的時候增加一個version（版本控制字段），每次需要更新余額的時候，先獲取對象，update的時候根據(jù)version和id為條件去更新，如果更新回來的數(shù)量為0，說明version已經(jīng)變更
需要重復一次更新操作，如下：sql腳本
update user_balance set Balance = #{balance,jdbcType=DECIMAL},Version = Version+1 where Id = #{id,jdbcType=BIGINT} and Version = #{version,jdbcType=BIGINT}
這是一種不使用數(shù)據(jù)庫鎖的方法，解決方式也很巧妙。當然，在大量并發(fā)的情況下，一次扣款需要重復多次的操作才能成功，還是有不足之處的。不知道還有沒有更好的方法。
當 web 日志中出現(xiàn)行鎖超時錯誤后，很多開發(fā)都會找我來排查問題，這里說下問題定位的難點！1. MySQL 本身不會主動記錄行鎖等待的相關(guān)信息，所以無法有效的進行事后分析。2. 鎖爭用原因有多種，很難在事后判斷到底是哪一類問題場景，尤其是事后無法復現(xiàn)問題的時候。3. 找到問題 SQL 后，開發(fā)無法有效從代碼中挖掘出完整的事務，這也和公司框架-產(chǎn)品-項目的架構(gòu)有關(guān)，需要靠 DBA 事后采集完整的事務 SQL 才可以進行分析。
MySQL 5.1支持對MyISAM和MEMORY表進行表級鎖定，對BDB表進行頁級鎖定，對InnoDB表進行行級鎖定。
如果不能同時插入，為了在一個表中進行多次INSERT和SELECT操作，可以在臨時表中插入行并且立即用臨時表中的記錄更新真正的表。
這可用下列代碼做到：
mysql LOCK TABLES real_table WRITE, insert_table WRITE;
mysql INSERT INTO real_table SELECT * FROM insert_table;
mysql TRUNCATE TABLE insert_table;
mysql UNLOCK TABLES;
重慶分公司
重慶分公司
