結論：當一個事務要對錶進行鎖定時，首先會獲取相應的意向鎖。其他事務可以透過檢查意向鎖來判斷是否有其他事務在更細粒度的級別上對錶進行了鎖定。這有助於避免衝突和提高併發效能
在討論此問題之前我們應當明確兩個前提：
- 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無需再去逐行分析是否有資料被持有行級排他鎖，提升了效率。