MySQL中的鎖
概述
MyISAM支持表鎖，InnoDB支持表鎖和行鎖，默認為行鎖
表級鎖：開銷小，加鎖快，不會出現(xiàn)死鎖。鎖定粒度大，發(fā)生鎖沖突的概率最高，并發(fā)量最低
行級鎖：開銷大，加鎖慢，會出現(xiàn)死鎖。鎖力度小，發(fā)生鎖沖突的概率小，并發(fā)度最高
MyISAM表級鎖
鎖模式
- show status like 'table%' 可以分析鎖爭奪情況
- 表級鎖分為兩種模式：共享讀鎖，獨占寫鎖
- 讀讀共享，讀寫互斥，寫寫互斥，寫讀互斥（比如寫讀互斥，當一個用戶對user表進行寫的時候，會阻塞其他用戶的寫操作和讀操作）
加表鎖
- 在select的時候自動加讀鎖，在update delete insert時，自動加寫鎖
- 一般不需要用戶用lock table 命令直接顯式加鎖
顯示加表鎖時
- session1顯示給user表加鎖
lock table user read;
- session1此時不能讀取未鎖定的class表，所以lock table時要一次性鎖定要用到的表
- session1此時不能進行更新和插入，只能進行讀取
- 其他session可以讀取user表，但是更新會阻塞，而插入不會阻塞（可以通過設置concurrent_insert 系統(tǒng)變量來控制并發(fā)插入行為）
鎖調度
- 當一個進程請求user表的讀鎖，一個進程請求user表的寫鎖，即使讀請求先到，也是請求寫鎖成先成功
- 所以，MyISAM不適合大量的更新，因為大量更新會導致查操作很難獲得讀鎖
InnoDB行級鎖
行鎖
- 通過 show status like 'InnoDB_row_lock' 來分析行鎖爭奪情況
- 共享鎖S：允許一個事務去讀一行，阻止其他事務獲得相同數(shù)據集的排他鎖
- 排他鎖X：允許獲得排它鎖的事務更新數(shù)據，阻止其他事務取得相同數(shù)據集的共享鎖和排他鎖
意向鎖
- 所謂意向鎖就是意圖拿到鎖，所以要獲得共享鎖時，需要先獲得意向共享鎖
- 意向共享所IS，一個事務給一個數(shù)據行加共享鎖時，必須先獲得表的IS鎖
- 意向排它鎖IX，一個事務給一個數(shù)據行加排他鎖時，必須先獲得該表的IX鎖
間隙鎖
- 范圍查詢時，比如select * from user where id>50 ，這個時候即使最大id為51，不僅會給符合條件的行加鎖，也會給id大于51（不存在的記錄）的加鎖，這就是間隙鎖
- 間隙鎖解決了事務并發(fā)的幻讀問題
兼容情況
| 鎖 | S | X | IS | IX |
|---|---|---|---|---|
| S | Yes | No | Yes | No |
| X | No | No | No | No |
| IS | Yes | No | Yes | Yes |
| IX | No | No | Yes | Yes |
加鎖
- 意向鎖是InnoDB自動加的
- 對于update insert delete 會自動加排它鎖
- 對于select不會自動加鎖
- Select * from user LOCK IN SHARE MODE 手動添加共享鎖
- select * from user For update 手動添加排它鎖
行鎖使用方式
- 通過索引條件檢索數(shù)據時，才使用行鎖，否則用表鎖
- 也就是如果select的where列不是索引列，那么此時，實際上是給整個表加鎖
- 檢索條件是索引時，又分索引是聚集索引還是非聚集索引，如果是聚集索引（索引上葉節(jié)點存放的整條記錄），在聚集索引上的加上行鎖，而如果是非聚集索引，要在非聚集索引記錄上加行鎖，又要在聚集索引上加行鎖
什么時候使用表鎖
- 事務需要更新表的大部分數(shù)據。如果每一行都加上排他鎖，鎖沖突嚴重，那么此時執(zhí)行效率低
- 事務涉及多個表，比較復雜
死鎖
MyISAM
- 由于加的是表鎖，一次性鎖定要需要的表，所以不會出現(xiàn)死鎖
InnoDB
- 死鎖一般是事務相互等待對方資源
- 發(fā)生死鎖后，會自動檢測，并讓一個事務釋放鎖并回退
| session1 | session2 |
|---|---|
| update user set username='jiajun' where id=1 | update user set username='jiajun' where id=2 |
| update user set username='jiajun' where id=2 | update user set username='jiajun' where id=1 |
- 上面就是死鎖的列子
樂觀鎖與悲觀鎖
- 樂觀鎖和悲觀鎖是一種思想，不是上面提到的數(shù)據庫提供的鎖，是并發(fā)控制的一種手段
- 有這樣的場景，兩個事務對商品（id=666）進行下單
樂觀鎖
- 有一個statu字段，未下單為0，下單為1
- 先查statu字段，下單進行更新， 再查詢一次statu看是否與之前查的一樣，一樣的話commit，不一樣的話rollback
- 實現(xiàn)方式：加一個版本號或者時間戳，提交前進行一次比較
悲觀鎖
- 直接對id為666的行加排他鎖
- 實現(xiàn)方式：通過數(shù)據庫的鎖機制進行加鎖
對比
- 悲觀鎖比較謹慎，采用加鎖機制，一定程度下降低了并發(fā)性
- 樂觀鎖認為一般情況下不會發(fā)生沖突，并發(fā)性較好
- 從沖突量和重試代價來衡量，如果沖突很少，或者重試代價不會很嚴重，那么通常情況下應該選擇樂觀鎖，因為它能得到更好的并發(fā)性，而且更容易實現(xiàn)。但是，如果沖突的代價嚴重，那么就需要使用悲觀策略
兩段鎖原則
兩段鎖
- 是一個加鎖原則，一種協(xié)議
- 鎖操作分為兩個階段，加鎖階段只加鎖不放鎖，解鎖階段只放鎖不加鎖
- 比如一個事務中兩個update語句，此時執(zhí)行完第一個update不會立刻放鎖，等加鎖階段完成后再進行放鎖，也就是加鎖和解鎖不相交
- 事務開始后就處于加鎖階段，一直到執(zhí)行ROLLBACK和COMMIT之前都是加鎖階段。ROLLBACK和COMMIT使事務進入解鎖階段，即在ROLLBACK和COMMIT模塊中DBMS釋放所有封鎖。
我覺得分享是一種精神，分享是我的樂趣所在，不是說我覺得我講得一定是對的，我講得可能很多是不對的，但是我希望我講的東西是我人生的體驗和思考，是給很多人反思，也許給你一秒鐘、半秒鐘，哪怕說一句話有點道理，引發(fā)自己內心的感觸，這就是我最大的價值。（這是我喜歡的一句話，也是我寫博客的初衷）
作者：jiajun 我的博客園： http://www.cnblogs.com/-new/
