結論:當一個事務要對錶進行鎖定時,首先會獲取相應的意向鎖。其他事務可以通過檢查意向鎖來判斷是否有其他事務在更細粒度的級別上對錶進行了鎖定。這有助於避免衝突和提高併發性能 在討論此問題之前我們應當明確兩個前提: Innodb存儲引擎支持行鎖和表鎖共存 行鎖與表鎖之間互不衝突 意向鎖是表級別的鎖,意向鎖 ...
結論:當一個事務要對錶進行鎖定時,首先會獲取相應的意向鎖。其他事務可以通過檢查意向鎖來判斷是否有其他事務在更細粒度的級別上對錶進行了鎖定。這有助於避免衝突和提高併發性能
在討論此問題之前我們應當明確兩個前提:
- Innodb存儲引擎支持行鎖和表鎖共存
- 行鎖與表鎖之間互不衝突
意向鎖是表級別的鎖,意向鎖之間、意向鎖與表級別的共用鎖、排他鎖的相容性關係如下:
假設目前有一張業務表t_business,主鍵b_id,在某種業務場景下 事務A需要對數據行增加排他鎖
SELECT xxx,xxx FROM t_business WHERE b_id = x FOR UPDATE;
此時 事務A實際上持有了兩把鎖 一個是表t_business的表級的意向排他鎖,一個是b_id=x的行級排他鎖
之後 事務B來了,想對錶t_business加表級別的共用鎖,由於共用鎖和排他鎖互斥,因此事務B在對錶加共用鎖之前需要明確:表上是否有行級/表級 排他鎖,由於事務A持有了表t_business的意向排他鎖,因此事務B無需再去逐行分析是否有數據被持有行級排他鎖,提升了效率。