一種提高共享資源併發效率的方式是合理的規劃鎖的範圍。僅僅鎖住你要修改的部分當然比全表鎖住要好。所以，我們儘可能的最小化鎖的範圍，因為不相干的部分，本身也互不干擾。

不過，也要考慮到，鎖是消耗資源的。每種鎖的操作都有消耗，例如：獲得鎖，檢查鎖是否可用，釋放鎖等。如果系統花了過多的資源在鎖的操作上，那麼併發的效能就會受到影響。

鎖的策略就是在鎖的消耗和資料安全之間尋求一種平衡，這種平衡會影響到效能。大部分商業資料庫沒有給你選擇的機會，一般都採用人們所熟知的行鎖，並通過內部一系列複雜的機制保持效率。

MySQL給了你選擇的權力。它的儲存引擎可以選擇自己鎖策略和粒度。因此，鎖的設計對於儲存引擎的實現來說是非常重要的。不同的儲存引擎，可以根據不同應用場景設計出特定的高效的鎖策略。下面，我們來看下兩種熟知的鎖策略。

表鎖

MySQL中最基本的鎖策略，也是消耗最低的鎖。表鎖跟之前提到的郵箱的鎖類似，它鎖住整張表。當客戶端想要寫表（insert,delete,updata）的時候，它獲得寫鎖。此時所有其他的讀寫操作都被阻止。當沒有人寫的時候，讀操作可以獲得鎖，並且不和其他的讀鎖互斥。

表鎖針對特定的場景有很多變種，以提供更好的效能。比如，READ LOCAL 表鎖，允許一些型別併發寫操作。寫鎖比讀鎖有更高的優先順序。也就是說，即使讀請求早於寫請求排在佇列中，寫請求也可以有先獲得鎖。

儘管儲存引擎本身可以管理鎖。MySQL自身也擁有很多表級的鎖用於一些特定的場合。比如，對於ALTER Table操作，MySQL就用了表級鎖，而不管你選擇了何種儲存引擎。

行鎖

這種鎖的型別提供了最好的併發效率同時也消耗最多的資源。行級鎖在InnoDB和XtraDB儲存引擎中提供。行級鎖在儲存引擎層而不是伺服器實現。服務層完全不關心儲存引擎層鎖的實現方式，在本章後面的部分以及本書中，都將看到各種儲存引擎有其自己的鎖的實現方式。