各位看官，大家早安午安晚安呀~~~
如果您覺得這篇文章對您有幫助的話
歡迎您一鍵三連，小編盡全力做到更好
歡迎您分享給更多人哦
今天我們來學習：MySQL鎖的分類 && MVCC和S/X鎖的互補關系
1.鎖分類
1.按鎖粒度分類：全局鎖，表級鎖，行級鎖
2.按照鎖模式分類：.共享鎖（Shared Lock，S 鎖），排他鎖（Exclusive Lock，X 鎖）
3.特殊鎖類型: 意向鎖（表鎖，Intention lock），?間隙鎖（Gap Lock），臨鍵鎖（Next-Key Lock）
2.按鎖粒度分類
2.1.?全局鎖（Global Lock）
- 特點：對整個數據庫實例加鎖，阻塞所有 DML 和 DDL 操作。
- 命令：
FLUSH TABLES WITH READ LOCK;- 優點：
- 實現簡單，確保數據一致性（如全量備份）。
2.2.?表級鎖（Table Lock）
- 特點：對整張表加鎖，開銷小、加鎖快。
- 命令：
LOCK TABLES table_name READ/WRITE;- 優點：
- 開銷小，適合批量操作（如批量插入）
2.3.行級鎖
?行級鎖（Row Lock）
- 特點：對索引記錄加鎖，僅 InnoDB 存儲引擎支持。
- 優點：
- 鎖粒度最小，并發性能最高（不同事務可同時操作不同行）。
3.按照鎖模式分類
1. 共享鎖（Shared Lock，S 鎖）
核心規則：
事務對資源加 S 鎖后，允許其他事務加 S 鎖（共享讀），但禁止其他事務加 X 鎖（禁止寫）。
即：“可以同時讀，不能同時寫”。適用場景：
僅讀取數據，不修改時使用（如SELECT ... LOCK IN SHARE MODE;）。
2.排他鎖（Exclusive Lock，X 鎖）
核心規則：
事務對資源加 X 鎖后，禁止其他事務加任何鎖（既不能讀，也不能寫）。
即：“寫的時候，既不能同時讀，也不能同時寫”。適用場景：
修改數據時使用（如UPDATE/DELETE，數據庫會自動加 X 鎖；或顯式加鎖SELECT ... FOR UPDATE;）。
意向鎖是表級鎖，它的設計是為了協調行級鎖和表級鎖的關系，避免 “行鎖與表鎖” 之間的沖突檢測效率低下。
4.問題：
4.1. 為什么需要意向鎖？
它的核心作用：是通過表級標記?優化 行級鎖和表級鎖之間的沖突檢查，減少鎖檢查的開銷
假設沒有意向鎖，當事務 A 對表中某行加 S 鎖，此時事務 B 想對整個表加 X 鎖（如ALTER TABLE），數據庫需要：
- 檢查表中所有行是否有 S 鎖 / X 鎖（逐行掃描）。
- 若表中數據量極大（如 1000 萬行），逐行檢查會導致性能災難。
意向鎖的作用：提前聲明 “事務想對表中的行加 S 鎖或 X 鎖”，讓表級鎖的沖突檢測只需檢查意向鎖，無需掃描全行。
2. 意向鎖的類型
意向鎖是表級鎖，分為兩種：
- 意向共享鎖（IS 鎖）：事務聲明 “未來可能對表中某些行加 S 鎖”。
- 意向排他鎖（IX 鎖）：事務聲明 “未來可能對表中某些行加 X 鎖”。
3. 意向鎖的工作流程
事務對行加 S 鎖 / X 鎖前，必須先對表加對應的意向鎖：
- 事務想對某行加 S 鎖 → 先對表加 IS 鎖 → 再對行加 S 鎖。
- 事務想對某行加 X 鎖 → 先對表加 IX 鎖 → 再對行加 X 鎖。
這樣的話 =》 如果加表鎖的話，一看到有意向鎖就 阻塞等待
總之：意向鎖既是一種標記（標記事務的意圖，它不直接鎖定任何行數據，而是在表級別記錄事務的操作方向（讀還是寫）），也是真正的鎖（有鎖的阻塞和兼容規則）
它的核心作用：是通過表級標記優化行級鎖和表級鎖之間的沖突檢查，減少鎖檢查的開銷
4.2總結：MVCC 與鎖的互補關系
為啥有mvcc還需要互斥鎖 和 排他鎖？？？
1.肯定是mvcc有局限性呀
MVCC 的優勢是提升讀寫并發性能，但它無法解決所有場景的并發問題，主要局限包括：
- 無法處理 “寫寫沖突”：多個事務同時修改同一行數據時，MVCC 只能通過 “后提交的事務覆蓋先提交的” 或 “事務回滾” 處理，無法保證修改的原子性和一致性（必須靠鎖解決）；
- 無法滿足 “強一致性讀” 需求：如果業務要求 “讀取的數據必須是最新的，且在讀取期間不被修改”（如金融對賬、庫存扣減前的校驗），MVCC 的 “讀歷史版本” 機制就不適用了；
- 無法處理范圍操作的并發問題：如
SELECT ... FOR UPDATE（鎖定查詢范圍內的所有行），MVCC 無法保證范圍操作的原子性（必須靠鎖鎖定范圍）
2.MVCC 和 S/X 鎖并非對立，而是協同工作：
- MVCC 負責優化 “讀寫并發”：讓讀操作無需加鎖，提升查詢性能；
- S/X 鎖負責解決 “寫寫沖突” 和 “強一致性需求”：保證修改的原子性、數據的一致性，以及特殊場景下的讀寫安全。
例如：
- 普通
SELECT（無鎖）：通過 MVCC 讀取歷史版本，不阻塞寫，提升并發；SELECT ... FOR SHARE（加 S 鎖）（強一致性需求）：通過 S 鎖保證讀取最新數據，且期間不被修改；UPDATE/DELETE：通過 X 鎖（寫寫沖突）保證同一時間只有一個事務能修改，避免臟寫。因此，即使有 MVCC，共享鎖和排他鎖仍是必不可少的 —— 它們解決了 MVCC 無法覆蓋的并發場景，共同保證數據庫的 ACID 特性。
5.間隙鎖和臨鍵鎖：
可以看我的另一篇博客講解
上述就是MySQL鎖的分類 && MVCC和S/X鎖的互補關系，不知道您對文章中的問題和思想是否都學會理解了呢？
能看到這里相信您一定對小編的文章有了一定的認可。
有什么問題歡迎各位大佬指出
歡迎各位大佬評論區留言修正~~