說起MySQL這個數(shù)據(jù)庫大師家里熱鬧得跟火車站似的，里面的鎖定機制可不就是站里的規(guī)矩。今天咱們就來聊聊MySQL插入數(shù)據(jù)時是怎么上鎖的，還有怎么避免讓人頭疼的死鎖問題。當然，我還會告訴你幾個提升批量插入速度的小妙招。你準備好了嗎？那咱們就一起去看看MySQL鎖背后的秘密！

1.鎖的概念復習：不只是簡單的鎖門

你猜怎么著?MySQL里面的鎖可不是隨便關門那么簡單的!它還有個厲害的武器，就是間隙鎖，用來避免誤讀。此外，如果要改動數(shù)據(jù)的話，還需要用行鎖。這兩樣合在一起，就成了next-keylock。這樣一來，數(shù)據(jù)庫里的數(shù)據(jù)就像穿上了防護服，前后都能保持一致。

你往數(shù)據(jù)庫里插入新數(shù)據(jù)時，如果存在唯一索引，MySQL就得看看這東西是不是重復了。這時候，要用到“當前讀”功能。啊找到相同關鍵字了？還被互斥鎖鎖定著？那MySQL就給你加個S鎖（也就是共享鎖），耐心等待。這就好比你想去人多的游樂園，得等到別人玩完了才能進去。

2.插入操作的加鎖過程：不僅僅是插入那么簡單

把新的數(shù)據(jù)丟進數(shù)據(jù)庫時，可不能隨便亂塞。要是翻到的那條記錄有唯一索引，那么MySQL馬上給你上X鎖，好比給你的路上設置個單行車道，這樣你的車就能暢快通過，不用擔心別人的車會撞上來。

但是，如果這個Key已經(jīng)被設置了互斥鎖的話，MySQL就得先掛個鎖，等待另一方解除鎖定才能進行操作。這其實就像是兩輛車在十字路口撞到了，大家都動彈不得，直接卡死了。

3.唯一索引下的死鎖：不僅僅是等待那么簡單

CREATE TABLE `t1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `a` varchar(5),
  `b` varchar(5),
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_name` (`a`,`b`)
);

說起唯一索引里的唯一鍵沖突，就像是兩輛車在十字路口相撞，每個人都想要搶著加鎖，結果就是車沒法動了。

想解決這個問題嗎？那就讓新數(shù)據(jù)先排排隊，這樣并發(fā)的時候就能避開死鎖！這就好像我們事先規(guī)劃好交通路線，確保車子都能順暢通行，避免堵車一樣。

4.提升批量插入效率：不僅僅是速度那么簡單

想快點插數(shù)據(jù)？咱們可以在business和database兩個角度下手。先說說business，把數(shù)據(jù)排個隊，這樣并發(fā)執(zhí)行也不怕卡！

在調整MySQL時，咱們可以試試看把innodb_flush_log_at_trx_commit設成0，這樣就能減少IO的壓力，redolog的寫入也就不會太勤快，全都交給后臺去搞定。這就好比是優(yōu)化路口的紅綠燈，讓車子跑得更快，等待的時間也會變短！

5.實驗驗證：不僅僅是理論那么簡單

begin;
delete from t1 where a = '25'
commit;
begin;
INSERT ignore INTO `t1` (`a`, `b`) VALUES('25','1')
commit;

試試看新學會的插入加鎖法，我們做個小游戲來看成果。先在電腦上用MySQL5.7開三個窗口，別忘了關掉自動提交功能。按照下面的步驟來，你會發(fā)現(xiàn)就像堵車一樣，卡住了！這就是實踐檢驗真理的過程~

6.隱式鎖和鎖升級：不僅僅是加鎖那么簡單

說到隱式鎖，它是用INSERT命令的時候，不用擔心重復問題。因為這種鎖定叫“插入意向鎖”，也就是說你正打算把東西插進去！

簡單來說，你插入數(shù)據(jù)到鎖里面，如果存在重復，后面的交易只會用最新的那個信息，而這個信息可能已經(jīng)被占用了（就是沒提交成功嘛）。這時候它就開始找S鎖。

7.實際操作中的注意事項：不僅僅是理論那么簡單

日常工作中得注意一些小竅門！比如給已經(jīng)有索引的表格加新的內容，最好先按索引排序，就跟我們平時收拾東西一樣。

搞定IO壓力大的問題，簡單！咱們調整下redolog的存儲量，讓它在后臺默默工作就好。然后，把innodb_flush_log_at_trx_commit設置為0，也沒啥影響。

8.總結：不僅僅是加鎖那么簡單

=====================================
2023-03-08 15:15:13 0x7fa4 INNODB MONITOR OUTPUT
=====================================
略
------------------------
LATEST DETECTED DEADLOCK ## 最新的死鎖
------------------------
2023-03-08 15:10:12 0x7fa4 ## 這里顯示了最近一次發(fā)生死鎖的日期和時間
*** (1) TRANSACTION: ## 事務1
TRANSACTION 220709, ACTIVE 10 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 4 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 16, OS thread handle 25992, query id 158597 localhost 127.0.0.1 root update
INSERT ignore INTO `user` (`id`,`username`, `age`, `birthday`, `sex`, `address`, `update_time`) VALUES (55,'小明', 5, '2019-09-17 19:12:37', '男', '杭州', '2022-09-01 16:03:25')
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:  
## 解釋：事務1在等X鎖（主鍵索引space id 302 page no 3 n bits 88 index PRIMARY）
RECORD LOCKS space id 302 page no 3 n bits 88 index PRIMARY of table `mybatis_01`.`user` trx id 220709 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 19 PHYSICAL RECORD: n_fields 9; compact format; info bits 0
略
*** (2) TRANSACTION: ## 事務1
TRANSACTION 220708, ACTIVE 25 sec inserting
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 7, OS thread handle 32676, query id 158584 localhost 127.0.0.1 root update
INSERT ignore INTO `user` (`id`,`username`, `age`, `birthday`, `sex`, `address`, `update_time`) VALUES (55,'小明', 5, '2019-09-17 19:12:37', '男', '杭州', '2022-09-01 16:03:25')
*** (2) HOLDS THE LOCK(S): 
## 解釋：事務2持有S鎖（主鍵索引space id 302 page no 3 n bits 88 index PRIMARY，跟上面事務1等的X鎖為同一行，X鎖與S鎖互斥，因此事務1得等事務2釋放行鎖）
RECORD LOCKS space id 302 page no 3 n bits 88 index PRIMARY of table `mybatis_01`.`user` trx id 220708 lock mode S locks gap before rec
Record lock, heap no 19 PHYSICAL RECORD: n_fields 9; compact format; info bits 0
略
*** (2) WAITING FOR THIS LOCK TO BE GRANTED: 
## 解釋：事務2在等X鎖（主鍵索引space id 302 page no 3 n bits 88 index PRIMARY，跟上面事務1等的X鎖為同一把鎖，而事務1在等事務2持有的S鎖釋放，因此死鎖）
RECORD LOCKS space id 302 page no 3 n bits 88 index PRIMARY of table `mybatis_01`.`user` trx id 220708 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 19 PHYSICAL RECORD: n_fields 9; compact format; info bits 0
略
*** WE ROLL BACK TRANSACTION (2)
## 解釋：根據(jù)事務回滾成本，選擇事務2回滾，釋放S鎖
------------

咱們說了這么半天得出個結論來，那就是弄懂MySQL鎖這事兒沒那么容易！你看，光是INSERT鎖就讓人頭大，再加上唯一索引下可能出現(xiàn)的死鎖問題和大批量插入如何更順利，這些都得咱們深入研究并精心設計。只要咱們用心點兒，就能讓那個忙得團團轉的MySQL跑得飛快，不堵車，效率還高！

末尾再問下大伙兒，你們有沒碰到過上班時MySQL卡住死機的煩心事兒？咋解決的呀？來評論區(qū)跟我們說說唄！交流學習，一塊兒進步！覺得這篇文章有點用處就點個贊，分享出去，讓更多人受益！