從鎖的粒度進行對資料庫進行劃分等級

1. 表級鎖
2. 行級鎖
3. 頁級鎖（這個不常用）

（1）MySQL的表級鎖兩種模式：

1. 表級共享讀鎖（共享鎖）：

也就是在MyISAM引擎下，如果對一個表加了讀鎖的話，那麼這個表（user表吧）當前的A執行緒可以進行讀，但是不能對user表進行寫操作，如果又有一個B執行緒想要去讀取user表的時候，此時也是可以讀取user表的，但是不能對user表進行寫操作，會對B執行緒進行阻塞。

2. 行級共享寫鎖（排它鎖）：

同樣是在MyISAM的引擎下，如果對一個表加了寫鎖的情況下，就是說當我對user表加了寫鎖的時候，你其他人就不能讀、也不能寫對我這個加寫鎖的表進行任何操作了，就是這麼任性，如果你想進行操作你只能在外面排隊，等我釋放之後你才能進行操作。

總結：表鎖適合那些業務偏讀的一些場景

（2）MySQL的行鎖：

MySQL的行鎖主要偏向於InnoDB引擎，開銷大，加鎖慢，容易出現死鎖，但是行鎖的粒度最小，併發度也比較高。所以InnoDB和MYISAM的主要區別也就是兩點：

1. InnoDB可以支援事務，但是 MyISAM引擎不支援事務
2. InnoDB可以最大化的支援行鎖的最小粒度

2. Innodb中的行鎖與表鎖：只有通過索引條件檢索資料，InnoDB才使用行級鎖，否則，InnoDB將使用表鎖！

1. 在不通過索引條件查詢的時候,InnoDB 確實使用的是表鎖,而不是行鎖。
2. 由於 MySQL 的行鎖是針對索引加的鎖,不是針對記錄加的鎖,所以雖然是訪問不同行 的記錄,但是如果是使用相同的索引鍵,是會出現鎖衝突的。應用設計的時候要注意這一點。
3. 當表有多個索引的時候,不同的事務可以使用不同的索引鎖定不同的行,另外,不論 是使用主鍵索引、唯一索引或普通索引,InnoDB 都會使用行鎖來對資料加鎖
4. 即便在條件中使用了索引欄位,但是否使用索引來檢索資料是由 MySQL 通過判斷不同 執行計劃的代價來決定的,如果 MySQL 認為全表掃 效率更高,比如對一些很小的表,它 就不會使用索引,這種情況下 InnoDB 將使用表鎖,而不是行鎖。因此,在分析鎖衝突時, 別忘了檢查 SQL 的執行計劃,以確認是否真正使用了索引。

最重要的提醒一下：在使用索引的時候如果不給varchar型別的欄位加單引號，就會導致索引失效，造成全表掃描