共享鎖與排它鎖

共享鎖【s鎖】

又稱讀鎖，若事務t對資料物件a加上s鎖，則事務t可以讀a但不能修改a，其他事務只能再對a加s鎖，而不能加x鎖，直到t釋放a上的s鎖。這保證了其他事務可以讀a，但在t釋放a上的s鎖之前不能對a做任何修改。

排他鎖【x鎖】

又稱寫鎖。若事務t對資料物件a加上x鎖，事務t可以讀a也可以修改a，其他事務不能再對a加任何鎖，直到t釋放a上的鎖。這保證了其他事務在t釋放a上的鎖之前不能再讀取和修改a。

1.共享鎖只用於表級，排他鎖用於行級。

2.加了共享鎖的物件，可以繼續加共享鎖，不能再加排他鎖。加了排他鎖後，不能再加任何鎖。

3.比如乙個dml操作，就要對受影響的行加排他鎖，這樣就不允許再加別的鎖，也就是說別的會話不能修改這些行。同時為了避免在做這個dml操作的時候，有別的會話執行ddl，修改表的定義，所以要在表上加共享鎖，這樣就阻止了ddl的操作。

4.當執行ddl操作時，就需要在全表上加排他鎖

上面都是一些概念性的東西，下面我從事務的隔離級別上討論一下這兩種鎖：

事務有四大隔離級別（隔離級別由高到低）：

（1）serializable（序列化）：乙個事務在執行過程中完全看不到其他事務對資料庫所做的更新（事務執行的時候不允許別的事務併發執行。事務序列化執行，事務只能乙個接著乙個地執行，而不能併發執行。）。

（2）repeatable read（可重複讀）：乙個事務在執行過程中可以看到其他事務已經提交的新插入的記錄，但是不能看到其他其他事務對已有記錄的更新。

（3）read commited（讀已提交資料）：乙個事務在執行過程中可以看到其他事務已經提交的新插入的記錄，而且能看到其他事務已經提交的對已有記錄的更新。

（4）read uncommitted（讀未提交資料）：乙個事務在執行過程中可以看到其他事務沒有提交的新插入的記錄，而且能看到其他事務沒有提交的對已有記錄的更新。

他們到底實現了是麼樣的鎖呢？我們乙個乙個看：

新增範圍鎖（比如表鎖，頁鎖等，關於range lock，我也沒有很深入的研究），直到transaction a結束。以此阻止其它transaction b對此範圍內的insert，update等操作。

幻讀，髒讀，不可重複讀等問題都不會發生。

對於讀出的記錄，新增共享鎖直到transaction a結束。其它transaction b對這個記錄的試圖修改會一直等待直到transaction a結束。

可能發生的問題：當執行乙個範圍查詢時，可能會發生幻讀。

在transaction a中讀取資料時對記錄新增共享鎖，但讀取結束立即釋放。其它transaction b對這個記錄的試圖修改會一直等待直到a中的讀取過程結束，而不需要整個transaction a的結束。所以，在transaction a的不同階段對同一記錄的讀取結果可能是不同的。

可能發生的問題：不可重複讀。

read uncommitted(未提交讀)

不新增共享鎖。所以其它transaction b可以在transaction a對記錄的讀取過程中修改同一記錄，可能會導致a讀取的資料是乙個被破壞的或者說不完整不正確的資料。

另外，在transaction a中可以讀取到transaction b（未提交）中修改的資料。比如transaction b對r記錄修改了，但未提交。此時，在transaction a中讀取r記錄，讀出的是被b修改過的資料。

可能發生的問題：髒讀。