mysql InnoDB引擎的行鎖和表鎖

之前是有接觸行鎖和表鎖但是由於沒有實際應用過也只是大概了解，前兩天就遇到了併發同時對一條記錄進行修改。mysql肯定會讓修改請求排隊，也就是說加了鎖，但是mysql預設加的是表鎖，但是會影響效率，所以我們需要用行鎖。

表鎖：顧名思義就是對整張表進行加鎖，同一時刻整張表所有記錄都被霸佔，雖然不會出現死鎖問題但是鎖衝突高堵塞高，併發低。

行鎖：很明顯只對某一行進行加鎖，這樣表的其餘行並不會被占用，衝突低，併發高，但是死鎖很可能出現。

鎖衝突：競爭資源已經被持有，按順序執行。

死鎖：就是你請求的被別人鎖住，被人請求被你鎖住了，對方都沒法進行下去。

首先行鎖是innodb預設的鎖，但是在篩選條件裡面沒有索引欄位時就會把整個表鎖住，下面會給出測試例子，最後會講下mysql innodb引擎為啥需要使用索引來完成對行加鎖。

lock in share mode 如： select * from user where user_name='wzzf' lock in share mode

for update 如：select * from user where user_name='wzzf' for update

下面給出測試例子：

先開個讀鎖

begin; select * from tyg_consumer_chain_sell_order o where o.consumer_chain_order_number=26911523448454 lock in share mode

再開個讀鎖，讀同一行

begin; select * from tyg_consumer_chain_sell_order o where o.consumer_chain_order_number=26911523448454 lock in share mode

兩個都查詢出來了，但是再開個寫鎖就一直沒有停止，說明是被鎖住了，後來停止報

證明了讀鎖可以共享讀，其他執行緒不能加寫鎖。

寫鎖就不再贅述，開啟了寫鎖之後其他執行緒連加讀鎖都不允許。

然後處理讀其他的都是預設加寫鎖的

行鎖必須要索引才能實現，否則會自動鎖全表，兩個事務可以用同乙個索引，下面給出例子：

讀鎖由於不排除其他執行緒再加讀鎖比較難測試，所以下面用寫鎖測試，先測試沒加所以字段進行加鎖，對不同記錄進行加鎖，如果都加鎖成功說明是加了行鎖，反之則是預設鎖全表。

下面的consumer_chain_order_number是不會重複的，但沒有索引

-- 馬上顯示查詢結果 begin; select * from tyg_consumer_chain_sell_order o where o.consumer_chain_order_number=26911523448454 for update

--一直沒有結束知道等待超時 begin; select * from tyg_consumer_chain_sell_order o where o.consumer_chain_order_number=55181523448554 for update

說明了預設鎖全表，接下來試下有索引的字段，這個表的主鍵

begin; select * from tyg_consumer_chain_sell_order o where o.consumer_chain_order_id=1 for update

begin; select * from tyg_consumer_chain_sell_order o where o.consumer_chain_order_id=2 for update

都查詢出來了結果，說明鎖住了行

這個問題本來我是想去深挖下，但是想想又覺得沒必要，有索引就能快速定位這個行，沒有索引資料庫也沒不能及時鎖住行需要全表掃瞄，為了安全只能把整個表鎖住。