MySQL學習之MySQL基本架構與鎖

更新時間：2023年03月30日 14:55:21 作者：摳腳的大灰狼

這篇文章主要介紹了MySQL的基本架構和鎖，鎖的分類有兩種有按粒度分，按功能，也有不同的類型，感興趣的小伙伴可以參考閱讀

MySql架構

SQL Layer
- Connection Pool : 連接池，用于接收連接請求和管理連接。
- ManagementService&Utilities 管理服務組件和工具組件，主要提供了一些備份，安全，主從，集群，等功能。
- SQL Interface：主要提供了SQL語句接口。包括SQL解析器，優(yōu)化器，緩存等。將我們輸入的SQL語句，解析成節(jié)點樹，然后傳遞給存儲引擎執(zhí)行。
Storage Engine Layer：可插拔式的存儲引擎。常用的有InnoDB，MyISAM等
File System : 底層文件系統(tǒng)。保存數(shù)據(jù)，索引，日志等文件。

MySQL鎖

鎖的分類

按粒度分

全局鎖（鎖database，由SQL Layer層實現(xiàn)）
表級鎖（由SQL Layer層實現(xiàn)）
- 表數(shù)據(jù)鎖
- 元數(shù)據(jù)鎖
行級鎖（由存儲引擎實現(xiàn)，如InnoDB）:

可以鎖行，也可以鎖行與行之間的間隙

按功能分

共享鎖（S鎖）（讀鎖）
排他鎖（X鎖）（寫鎖）

鎖的演示

表鎖

表數(shù)據(jù)鎖

-- 對product表加讀鎖
-- 其他進程仍然可以對product表進行讀取，但不能寫(包括加讀鎖本身這個進程，也無法寫)
lock table product read;
-- 加鎖后，該進程只能訪問product表,無法訪問其他表。
select * from seller;
ERROR 1100 (HY000): Table 'seller' was not locked with LOCK TABLES
-- 當然可以讓當前進程給seller表加鎖
lock table seller read;
-- 如此以來，便可以訪問seller表，但由于一個進程只能持有一個表鎖，故原先的product表鎖被釋放，product表無法訪問


-- 其他未持有鎖的session可以訪問任意表

-- 釋放鎖
unlock tables;
-- 或者
unlock table; 
-- 上面兩句效果一樣
-- 只會釋放當前連接進程所持有的表鎖，而不是釋放所有鎖，

-- 對product表加寫鎖
lock table product write;
-- 其他線程對product表既不能讀，也不能寫


-- 查看表鎖狀態(tài)
show open tables;

-- 注意，一個連接進程，最多只能持有1個表鎖

元數(shù)據(jù)鎖（Meta Data Lock）

MDL無需顯式使用，在訪問一個表時，會自動加元數(shù)據(jù)鎖。MDL的作用是為了保證讀寫的正確性。

MDL讀鎖：在對某個表進行增刪改查操作時，加MDL讀鎖。

MDL寫鎖：在對某個表的結構進行修改(DDL)時，加MDL寫鎖。

讀鎖之間不互斥，讀寫，寫寫之間互斥。這樣是為了保證對表結構操作的安全性。

MDL可以認為是表結構鎖。需要改表結構時，自動加MDL寫鎖，其他時候加MDL讀鎖

DML,DQL語句，會自動加MDL的讀鎖

DDL語句，會自動加MDL的寫鎖

-- 線程A
begin;
select * from product;
-- 在一個事務內，MDL鎖是一直被持有的

-- 此時另起一個，線程B
alter table product add type varchar(10);
-- 執(zhí)行上面的sql，會發(fā)現(xiàn)被阻塞住，因為線程B這一句需要MDL寫鎖

-- 再回到線程A
commit;
-- 線程A提交事務后，釋放MDL讀鎖
-- 此時能看到線程B的sql執(zhí)行成功

注意：如上圖所示，session A 和 session B可以正常執(zhí)行，session C 就被阻塞了，因為session C需要申請MDL寫鎖，關鍵是，session D也會被阻塞。當session A 提交后，會先執(zhí)行session D，最后再執(zhí)行session C。

觀察發(fā)現(xiàn)，如果先開啟事務，在事務里執(zhí)行DDL，先不提交當前事務。再另起一個線程，執(zhí)行DML，發(fā)現(xiàn)DML不會被阻塞。

這是因為DDL在執(zhí)行完成后，會自動立刻commit（自動commit后會釋放MDL寫鎖）。

申請MDL鎖的操作會形成一個隊列，隊列中寫鎖獲取優(yōu)先級高于讀鎖。一旦出現(xiàn)寫鎖等待，不但當前操作會被阻塞，同時還會阻塞后續(xù)該表的所有操作。事務一旦申請到MDL鎖后，直到事務執(zhí)行完才會將鎖釋放。（這里有種特殊情況如果事務中包含DDL操作，mysql會在DDL操作語句執(zhí)行前，隱式提交commit，以保證該DDL語句操作作為一個單獨的事務存在，同時也保證元數(shù)據(jù)排他鎖的釋放。

行鎖

行鎖是由存儲引擎實現(xiàn)的。InnoDB支持行鎖和事務，MyISAM不支持行鎖和事務。

InnoDB的行鎖是通過給索引項加鎖實現(xiàn)的。所以，若不是通過索引條件檢索的數(shù)據(jù)，InnoDB會使用表鎖。

InnoDB的行鎖

按照鎖定范圍分3種：

Record Lock：記錄鎖，鎖定索引中的一條記錄
Gap Lock：間隙鎖，鎖定記錄間的間隙
Next-Key Locks：記錄鎖+間隙鎖組合

按功能分為

共享讀鎖
排他寫鎖

DML語句（INSERT/UPDATE/DELETE）會自動加上排他鎖

對于普通SELECT語句，InnoDB不加鎖（是通過MVCC的一致性非鎖定讀的方式完成的，這個后序再做總結），可以通過以下方式，手動添加鎖

-- 共享讀鎖
SELECT * FROM product LOCK IN SHARE MODE;

-- 排他寫鎖
SELECT * FROM product FOR UPDATE;

-- 查看行鎖情況
show status like '%innodb_row_lock%';

意向鎖

是InnoDB實現(xiàn)的表級鎖，在內部使用，無需用戶干預。

MySQL有多粒度的鎖實現(xiàn)，即行鎖和表鎖。那么意向鎖存在的意義是為了協(xié)調行鎖和表鎖。試想事務A申請了某表某一行的寫鎖X，事務B申請了該表的寫鎖X，那么事務B按理說也能修改事務A鎖定的某一行，這就產生了沖突。如果沒有意向鎖，某事務申請表鎖時，可能就得一行一行的掃描，看看是不是所有行都沒有鎖，所有行都沒鎖時，才能成功加表鎖。這樣效率就會很低。

所以意向鎖的作用就是表明某個事務有加行鎖的意圖，即，有人鎖住了某一行，或者將要鎖住某一行，這樣在其他人在加表鎖時，就能直接根據(jù)意向鎖的情況，判斷是否能夠加表鎖，而不必一行一行掃描了。

意向共享鎖（IS）：加行共享鎖前，必須先取得IS鎖

意向排他鎖（IX）：加行排他鎖前，必須先取得IX鎖

意向鎖的作用主要是為了在針對全表操作時獲得性能提升。

比如：事務A對某一行加了鎖（無論是讀鎖還是寫鎖），事務B嘗試加表鎖，這時如果沒有意向鎖，就需要遍歷檢測每一行是否持有行鎖，這樣性能是極低的。

意向鎖只和表鎖互斥。