前言

mysql 的表鎖之?AUTO_INC, 是我們自增長的時候做并發(fā)控制的鎖?

主要是用于?自增長生成新的 id?的時候的控制?

在前面的文檔中,?我們又看到?mysql?這邊自增長的處理的相關(guān)的大概脈絡(luò)

但是?對于一些 并發(fā)控制的細節(jié),?我們當時?應(yīng)該是直接忽略掉了 ?

我們這里就來看一下?mysql 這里的?AUTO_INC?的一個實現(xiàn)?

當然?它的實現(xiàn) 有幾種方式,?模式選擇有?0, 1, 2

模式為 0 的場景下,?主要是?基于樂觀鎖,?每一個表映射一個?mutex, 來嘗試樂觀獲取鎖?

模式為 1 的場景下,?對于?INSERT, REPLACE 命令主要是?基于樂觀鎖,?每一個表映射一個?mutex, 來嘗試樂觀獲取鎖,?其他的場景基于?表自增長鎖

模式為?2 的場景下,?主要是基于和前面的 表共享鎖,?表排他鎖?一個級別的 表自增長鎖

我們這里核心關(guān)注的是 表自增長鎖 的相關(guān)實現(xiàn)

?

?

表自增長鎖

獲取?LOCK_AUTO_INC 這邊的實現(xiàn)?和 獲取其他表級別的鎖的主流程一致

差異在于?LOCK_AUTO_INC?和其他鎖的兼容性,?在之前?表共享鎖,?表排他鎖?的場景下面,?為了簡化問題,?我們是跳過了?LOCK_AUTO_INC, 這里我們來講?LOCK_AUTO_INC?代入進來看看?

?

從這里可以看到,?如果是我們?LOCK_AUTO_INC?這邊和?表意向鎖 是兼容的

和?LOCK_AUTO_INC?是不兼容的,?和?表共享鎖,?表排他鎖?是不兼容的

總結(jié)下來意思就是,?如果是?事務(wù)1?獲取的是?行鎖,?那么是不影響?事務(wù)2?獲取?表自增長鎖 的

如果是?事務(wù)1?獲取的是?表自增長鎖,?那么是會阻塞?事務(wù)2?獲取?表自增長鎖 的

如果是?事務(wù)1?獲取的是?表共享鎖,?表排他鎖,?那么是會阻塞?事務(wù)2?獲取?表自增長鎖 的

?

整體的這邊獲取?表自增長鎖 這邊的具體的 鎖表策略 分派方式如下

基本上三種策略就是?mutex樂觀鎖?+?mutex樂觀鎖, 表自增長鎖 + 表自增長鎖?

?

?

表自增長鎖的獲取和釋放

表自增長鎖?的獲取是在執(zhí)行 insert?sql 的時候

?

然后釋放 表自增長鎖 是在語句執(zhí)行完成之后釋放的?如下?

?

?

表自增長鎖阻塞的 N?中方式

表自增長鎖?的阻塞方式 就是上面提及的 表共享鎖,?表排他鎖,?表自增長鎖?被持有的情況下 ?

假設(shè)我們這里嘗試模擬?各種阻塞的方式,?事務(wù)1先進行執(zhí)行,?然后事務(wù)2嘗試獲取表排他鎖,?產(chǎn)生阻塞?

事務(wù)2?這邊執(zhí)行固定的?sql?語句如下?

begin;
INSERT INTO `test_02`.`tz_test_02`(`field1`, `field2`) VALUES ('field1', '11');
commit;

?

事務(wù)1獲取 表排他鎖 導(dǎo)致 事務(wù)2獲取MDL元數(shù)據(jù)鎖?阻塞

begin;
lock tables tz_test_02 write;
-- sleep 10min
unlock tables;
commit;

?

事務(wù)1獲取 表共享鎖 導(dǎo)致 事務(wù)2獲取MDL元數(shù)據(jù)鎖?阻塞

begin;
lock tables tz_test_02 read;
-- sleep 10min
unlock tables;
commit;

?

?

事務(wù)1?獲取了?表自增長鎖,?導(dǎo)致事務(wù)2獲取MDL元數(shù)據(jù)鎖?阻塞????????

?

?

完

?

?

?