關於資料庫的鎖粒度

一種提高共享資源併發性的方式就是讓鎖定物件更具有選擇性。盡量只鎖定需要修改的部分資料，而不是所有資源。更理想的方式是，只對會修改的資料片進行精確鎖定。任何時候，在給定的資源上，鎖定的資料量越少，則系統的併發程度越高，只要互相之間不發生衝突就可以了。

問題是加鎖也需要消耗資源。鎖的各種操作，包括獲得鎖，檢查鎖是否已經消除，釋放鎖等，都會增加系統的開銷。

所謂鎖策略，就是在鎖的開銷和資料安全性之間尋找乙個平衡點。

mysql提供了多種選擇。每種mysql的儲存引擎都可以實現自己的鎖粒度和鎖策略。在儲存引擎的設計中，鎖管理是乙個非常重要的決定。將鎖粒度固定在某個級別，可以提供對一些場景的良好的支援，但同時會失去對另外一些場景的支援的效能。

1，表鎖

表鎖是mysql中最基本的鎖策略，並且是開銷最小的策略。表鎖非常適用於前面描述的郵箱加鎖機制：它會鎖定整張表。乙個使用者在對錶進行寫操作時，需要先獲得寫鎖，這樣會阻塞其他使用者對該錶的所有讀寫操作。只有在沒有寫鎖時，其他的讀取使用者才能獲取讀鎖，讀鎖之間是不互相阻塞的。

儘管儲存引擎可以管理自己的鎖，mysql本身還是會使用各種有效的表鎖來實現不同的目的。例如，伺服器會為諸如alter table之類的語句使用表鎖，而忽略儲存引擎的鎖機制。

2，行級鎖

行級鎖可以最大程度的支援併發處理，同時也帶來了最大的鎖開銷。眾所周知，在innodb和xtradb以及其他一些儲存引擎中實現了行級鎖。行級鎖只在儲存引擎層實現，而mysql伺服器層沒有實現。伺服器層完全不了解儲存引擎中的鎖實現。