mysql樂觀鎖、悲觀鎖、共享鎖、排它鎖、行鎖、表鎖

樂觀鎖

總是假設最好的情況，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號機制和CAS算法實現。樂觀鎖適用于多讀的應用類型，這樣可以提高吞吐量

通常實現是這樣的：在表中的數據進行操作時(更新)，先給數據表加一個版本(version)字段，每操作一次，將那條記錄的版本號加1。也就是先查詢出那條記錄，獲取出version字段,如果要對那條記錄進行操作(更新),則先判斷此刻version的值是否與剛剛查詢出來時的version的值相等，如果相等，則說明這段期間，沒有其他程序對其進行操作，則可以執行更新，將version字段的值加1；如果更新時發現此刻的version值與剛剛獲取出來的version的值不相等，則說明這段期間已經有其他程序對其進行操作了，則不進行更新操作。

悲觀鎖

總是假設最壞的情況，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會阻塞直到它拿到鎖（共享資源每次只給一個線程使用，其它線程阻塞，用完后再把資源轉讓給其它線程）。傳統的關系型數據庫里邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。

共享鎖，又稱為讀鎖，是悲觀鎖的一種，可以查看但無法修改和刪除的一種數據鎖.

比如一個事務正在執行，沒有執行commit語句，別的事務只能查詢，而不能修改這個事務所對應行。。

所有事務的Select …..都加上lock in share mode：實現了寫鎖

排他鎖（Exclusive Locks，簡稱X鎖），又稱為寫鎖、獨占鎖, 若事務T對數據對象A加上X鎖，則只允許T讀取和修改A，其他任何事務都不能再對A加任何類型的鎖，直到T釋放A上的鎖。這就保證了其他事務在T釋放A上的鎖之前不能再讀取和修改A。

所有事務的Select ……都加上 for update：實現了讀鎖

通過查詢語句后面+for update使用，注意for update 一定要配合事務一起使用。

START TRANSACTION;

SELECT * FROM test WHERE id=1 for update;

COMMIT

我們可以使用命令設置MySQL為非autocommit模式：

set autocommit=0;

設置完autocommit后，我們就可以執行我們的正常業務了。具體如下：

//0.開始事務

begin;/begin work;/start transaction; (三者選一就可以)

//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;/commit work;

注：上面的begin/commit為事務的開始和結束，因為在前一步我們關閉了mysql的autocommit，所以需要手動控制事務的提交，在這里就不細表了。

上面的第一步我們執行了一次查詢操作：select status from t_goods where id=1 for update;

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

注：需要注意的是，在事務中，只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一筆數據時會等待其它事務結束后才執行，一般SELECT ... 則不受此影響。拿上面的實例來說，當我執行select status from t_goods where id=1 for update;后。我在另外的事務中如果再次執行select status from t_goods where id=1 for update;則第二個事務會一直等待第一個事務的提交，此時第二個查詢處于阻塞的狀態，但是如果我是在第二個事務中執行select status from t_goods where id=1;則能正常查詢出數據，不會受第一個事務的影響。

超賣現象和解決—》數據庫篇

1.不同用戶在讀請求的時候，發現商品庫存足夠，然后同時發起請求，進行秒殺操作，減庫存，導致庫存減為負數。

2.同一個用戶在有庫存的時候，連續發出多個請求，兩個請求同時存在，于是生成多個訂單。

對于第一種超賣現象;

(1)最簡單的方法，更新數據庫減庫存的時候，進行庫存限制條件，

update miaosha_goods set stock_count = stock_count - 1 where goods_id = #{goodsId} and stock_count >0

可以簡單的解決超賣的情況

但是不能完全避免；

（2）究其深層原因，是因為數據庫底層的寫操作和讀操作可以同時進行，雖然寫操作默認帶有隱式鎖（即對同一數據不能同時進行寫操作）但是讀操作默認是不帶鎖的，所以當用戶1去修改庫存的時候，用戶2依然可以都到庫存為1，所以出現了超賣現象。

解決方案：

可以對讀操作加上顯式鎖（即執行事務并 select ...語句最后加上for update）這樣一來用戶1在進行讀操作時用戶2就需要排隊等待了

但是問題來了，如果該商品很熱門并發量很高那么效率就會大大的下降，怎么解決？

解決方案：

我們可以有條件有選擇的在讀操作上加鎖，比如可以對庫存做一個判斷，當庫存小于一個量時開始加鎖，讓購買者排隊，這樣一來就解決了超賣現象。

（3）應用一個隊列緩存，將多線程變為單線程讀寫。

總結

以上是生活随笔為你收集整理的innodb 悲观锁 乐观锁_mysql乐观锁、悲观锁、共享锁、排它锁、行锁、表锁的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。