MySQL數據庫的鎖機制是什么

137次閱讀

沒有評論

共計 4415 個字符，預計需要花費 12 分鐘才能閱讀完成。

本篇內容介紹了“MySQL 數據庫的鎖機制是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓丸趣 TV 小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

為什么要加鎖？

問題背景

當多個用戶并發地存取數據時，在數據庫中就會產生多個事務同時存取同一數據的情況。若對并發操作不加控制就可能會讀取和存儲不正確的數據，破壞數據庫的一致性。

要解決的問題

多用戶環境下保證數據庫完整性和一致性

鎖是什么

在計算機科學中，鎖是在執行多線程時用于強行限制資源訪問的同步機制，即用于在并發控制中保證對互斥要求的滿足。

加鎖是實現數據庫并發控制的一個非常重要的技術。當事務在對某個數據對象進行操作前，先向系統發出請求，對其加鎖。加鎖后事務就對該數據對象有了一定的控制，在該事務釋放鎖之前，其他的事務不能對此數據對象進行更新操作。

鎖的分類

行

行級鎖

行級鎖是 Mysql 中鎖定粒度最細的一種鎖，表示只針對當前操作的行進行加鎖。行級鎖能大大減少數據庫操作的沖突。其加鎖粒度最小，但加鎖的開銷也最大。行級鎖分為共享鎖和排他鎖。

特點

開銷 D，加鎖慢；會出現死鎖；鎖定粒度最小，F 生鎖沖突的概率最低，并 F 度也最高。

表

表級鎖是 MySQL 中鎖定粒度最大的一種鎖，表示對當前操作的整張表加鎖，它實現簡單，資源消耗較少，被大部分 MySQL 引擎支持。最常使用的 MYISAM 與 INNODB 都支持表級鎖定。表級鎖定分為表共享讀鎖（共享鎖）與表獨占寫鎖（排他鎖）。

特點

開銷小，加鎖快；不會出現死鎖；鎖定粒度 D，F 出鎖沖突的概率最高，并發度最低。

頁

頁級鎖是 MySQL 中鎖定粒度介于行級鎖和表級鎖中間的一種鎖。表級鎖速度快，但沖突多，行級沖突少，但速度慢。所以取了折衷的頁級，一次鎖定相鄰的一組記錄。BDB 支持頁級鎖

特點

開銷和加鎖時間界于表鎖和行鎖之間；會出現死鎖；鎖定粒度界于表鎖和行鎖之間，并發度一般

MySQL 常用存儲引擎的鎖機制

MyISAM 和 MEMORY 采用表級鎖(table-level locking)

BDB 采用頁面鎖 (page-level locking) 或表級鎖，默認為頁面鎖

InnoDB 支持行級鎖 (row-level locking) 和表級鎖, 默認為行級鎖

InnoDB 行鎖是通過給索引上的索引項加鎖來實現的，InnoDB 這種行鎖實現特點意味著：只有通過索引條件檢索數據，InnoDB 才使用行級鎖，否則，InnoDB 將使用表鎖！

在實際應用中，要特別注意 InnoDB 行鎖的這一特性，不然的話，可能導致大量的鎖沖突，從而影響并發性能。

行級鎖都是基于索引的，如果一條 SQL 語句用不到索引是不會使用行級鎖的，會使用表級鎖。行級鎖的缺點是：由于需要請求大量的鎖資源，所以速度慢，內存消耗大。

實例說明

MySQL InnoDB 引擎默認的修改數據語句：update,delete,insert 都會自動給涉及到的數據加上排他鎖。

select 語句默認不會加任何鎖類型，如果加排他鎖可以使用 select …for update 語句，加共享鎖可以使用 select … lock in share mode 語句。

所以加過排他鎖的數據行在其他事務種是不能修改數據的，也不能通過 for update 和 lock in share mode 鎖的方式查詢數據，但可以直接通過 select …from…查詢數據，因為普通查詢沒有任何鎖機制。

行級鎖與死鎖

MyISAM 中是不會產生死鎖的，因為 MyISAM 總是一次性獲得所需的全部鎖，要么全部滿足，要么全部等待。而在 InnoDB 中，鎖是逐步獲得的，就造成了死鎖的可能。

在 MySQL 中，行級鎖并不是直接鎖記錄，而是鎖索引。索引分為主鍵索引和非主鍵索引兩種，如果一條 sql 語句操作了主鍵索引，MySQL 就會鎖定這條主鍵索引；如果一條語句操作了非主鍵索引，MySQL 會先鎖定該非主鍵索引，再鎖定相關的主鍵索引。在 UPDATE、DELETE 操作時，MySQL 不僅鎖定 WHERE 條件掃描過的所有索引記錄，而且會鎖定相鄰的鍵值，即所謂的 next-key locking。

當兩個事務同時執行，一個鎖住了主鍵索引，在等待其他相關索引。另一個鎖定了非主鍵索引，在等待主鍵索引。這樣就會發生死鎖。

發生死鎖后，InnoDB 一般都可以檢測到，并使一個事務釋放鎖回退，另一個獲取鎖完成事務。

共享鎖與排它鎖

共享鎖（Share Lock）

共享鎖又稱讀鎖，是讀取操作創建的鎖。其他用戶可以并發讀取數據，但任何事務都不能對數據進行修改（獲取數據上的排他鎖），直到已釋放所有共享鎖。

如果事務 T 對數據 A 加上共享鎖后，則其他事務只能對 A 再加共享鎖，不能加排他鎖。獲準共享鎖的事務只能讀數據，不能修改數據。

用法 SELECT … LOCK IN SHARE MODE;

在查詢語句后面增加 LOCK IN SHARE MODE，Mysql 會對查詢結果中的每行都加共享鎖，當沒有其他線程對查詢結果集中的任何一行使用排他鎖時，可以成功申請共享鎖，否則會被阻塞。其他線程也可以讀取使用了共享鎖的表，而且這些線程讀取的是同一個版本的數據。

排它鎖（eXclusive Lock）

排他鎖又稱寫鎖，如果事務 T 對數據 A 加上排他鎖后，則其他事務不能再對 A 加任任何類型的封鎖。獲準排他鎖的事務既能讀數據，又能修改數據。

用法 SELECT … FOR UPDATE;

在查詢語句后面增加 FOR UPDATE，Mysql 會對查詢結果中的每行都加排他鎖，當沒有其他線程對查詢結果集中的任何一行使用排他鎖時，可以成功申請排他鎖，否則會被阻塞。

樂觀鎖（Optimistic Lock）

是什么

假設認為數據一般情況下不會造成沖突，所以在數據進行提交更新的時候，才會正式對數據的沖突與否進行檢測，如果發現沖突了，則讓返回用戶錯誤的信息，讓用戶決定如何去做。

相對于悲觀鎖，在對數據庫進行處理的時候，樂觀鎖并不會使用數據庫提供的鎖機制。一般的實現樂觀鎖的方式就是記錄數據版本。

數據版本, 為數據增加的一個版本標識。當讀取數據時，將版本標識的值一同讀出，數據每更新一次，同時對版本標識進行更新。當我們提交更新的時候，判斷數據庫表對應記錄的當前版本信息與第一次取出來的版本標識進行比對，如果數據庫表當前版本號與第一次取出來的版本標識值相等，則予以更新，否則認為是過期數據。

實現數據版本有兩種方式，第一種是使用版本號，第二種是使用時間戳。

使用版本號實現樂觀鎖

使用版本號時，可以在數據初始化時指定一個版本號，每次對數據的更新操作都對版本號執行 + 1 操作。并判斷當前版本號是不是該數據的最新的版本號。

1. 查詢出商品信息
select (status,status,version) from t_goods where id=#{id}
2. 根據商品信息生成訂單
3. 修改商品 status 為 2
update t_goods
set status=2,version=version+1
where id=#{id} and version=#{version};

優點與不足

樂觀并發控制相信事務之間的數據競爭 (data race) 的概率是比較小的，因此盡可能做下去，直到提交的時候才去鎖定，所以不會產生任何鎖和死鎖。但如果直接簡單這么做，還是有可能會遇到不可預期的結果，例如兩個事務都讀取了數據庫的某一行，經過修改以后寫回數據庫，這時就遇到了問題

悲觀鎖（Pessimistic Lock）

是什么

在整個數據處理過程中，將數據處于鎖定狀態。悲觀鎖的實現，往往依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據）

悲觀鎖的流程

在對任意記錄進行修改前，先嘗試為該記錄加上排他鎖（exclusive locking）。

如果加鎖失敗，說明該記錄正在被修改，那么當前查詢可能要等待或者拋出異常。具體響應方式由開發者根據實際需要決定。

如果成功加鎖，那么就可以對記錄做修改，事務完成后就會解鎖了。

其間如果有其他對該記錄做修改或加排他鎖的操作，都會等待我們解鎖或直接拋出異常。

MySQL InnoDB 中使用悲觀鎖

要使用悲觀鎖，我們必須關閉 mysql 數據庫的自動提交屬性，因為 MySQL 默認使用 autocommit 模式，也就是說，當你執行一個更新操作后，MySQL 會立刻將結果進行提交。set autocommit=0;

//0. 開始事務
begin;
//1. 查詢出商品信息
select status from t_goods where id=1 for update;
//2. 根據商品信息生成訂單
insert into t_orders (id,goods_id) values (null,1);
//3. 修改商品 status 為 2
update t_goods set status=2;
//4. 提交事務
commit;

上面的查詢語句中，我們使用了 select…for update 的方式，這樣就通過開啟排他鎖的方式實現了悲觀鎖。此時在 t_goods 表中，id 為 1 的那條數據就被我們鎖定了，其它的事務必須等本次事務提交之后才能執行。這樣我們可以保證當前的數據不會被其它事務修改。

Java 的鎖機制

線程的同步問題

一段 synchronized 的代碼被一個線程執行之前，他要先拿到執行這段代碼的權限，在 java 里邊就是拿到某個同步對象的鎖（一個對象只有一把鎖）；如果這個時候同步對象的鎖被其他線程拿走了，他（這個線程）就只能等了（線程阻塞在鎖池等待隊列中）。取到鎖后，他就開始執行同步代碼(被 synchronized 修飾的代碼）；線程執行完同步代碼后馬上就把鎖還給同步對象，其他在鎖池中等待的某個線程就可以拿到鎖執行同步代碼了。這樣就保證了同步代碼在統一時刻只有一個線程在執行。

線程的同步方法：

1. 在需要同步的方法的方法簽名中加入 synchronized 關鍵字。

2. 使用 synchronized 塊對需要進行同步的代碼段進行同步。

3. 使用 JDK 5 中提供的 java.util.concurrent.lock 包中的 Lock 對象。

ThreadLocal

當使用 ThreadLocal 維護變量時，ThreadLocal 為每個使用該變量的線程提供獨立的變量副本，所以每一個線程都可以獨立地改變自己的副本，而不會影響其它線程所對應的副本。在 ThreadLocal 類中有一個 Map，用于存儲每一個線程的變量副本，Map 中元素的鍵為線程對象，而值對應線程的變量副本。使用 ThreadLocal 的典型場景如數據庫連接管理，線程會話管理等場景，只適用于獨立變量副本的情況，如果變量為全局共享的，則不適用在高并發下使用。

“MySQL 數據庫的鎖機制是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注丸趣 TV 網站，丸趣 TV 小編將為大家輸出更多高質量的實用文章！

正文完