數據庫 事物 鎖

事物中的鎖簡單說就是S共享鎖，X排它鎖

X鎖在全部事物中，一旦加上，持續到COMMIT才釋放

 

未提交讀 （READ UNCOMMITTED）：讀取時候不會加共享鎖，直接讀取

已提交讀（READ COMMITTED）：讀取時候加S鎖，讀完立馬釋放S鎖，會在事物完成前就立馬釋放S鎖

可重複讀（REPEATABLE READ）：讀取時候加S鎖，一直持續到事物提交纔會釋放S鎖，若是中間有數據插入，改模式會讀取到插入的數據，會出現幻想

可序列化（SERIALIZABLE）：讀取時候加S鎖，一直持續到事物提交纔會釋放S鎖，可是數據庫底層會有機制確保該隔離級別下

                             全部的操做都是串行，不會出現幻想，由於中間有數據插入，該模式下也讀取不到，應該是該模式比REPEATABLE READ

                             還多了範圍鎖。

 

http://www.javashuo.com/article/p-sntipflx-kk.html

https://www.cnblogs.com/jackson0714/p/TSQLFundamentals_08.html

https:///www.cnblogs.com/ljhdo/p/5037033.html

能夠經過這幾篇文章來理解上面幾種隔離級別

 

 

 

 

測試方法，建立一個表，CREATE TABLE [dbo].[Test]

(

[id] [int] IDENTITY(1,1) NOT NULL,//設置主鍵

[price] [float] NOT NULL,

)

 

//下面語句能夠找出來加鎖的事物

 

select    

   *,  

    OBJECT_NAME(resource_associated_entity_id) tableName    

from    

    sys.dm_tran_locks   

where    

    resource_type='OBJECT' 

//end

在測試時候會有死鎖，用kill pid;來結束；

 

可是必定要設置：

ALTER DATABASE   [databaseName] SET READ_COMMITTED_SNAPSHOT off;

或者

ALTER DATABASE [databaseName]  SET READ_COMMITTED_SNAPSHOT on  with rollback immediate

//禁用行版本控制模式，就能夠測試以上全部的事物特性，和理解的是同樣的；若是該選項打開，那麼將會用行版原本控制，參考mysql 或者sql server 的MVCC實現機制來理解

 

 

 

 

 

 

 

 

 

 

 

 

 

 

sqlserver新版本還有還有MYSQL ,ORACLE等都實現了MVCC機制，在該機制下READ COMMITTED，REPEATABLE READ讀取數據時候不會加S鎖，而是用了行版本控制來實現同樣的效果，可是佔用資源會更少，以上流程都是按照數據庫標準的悲觀鎖來設計的，基本主流的的數據庫都是按照這個模式來作的。

行版本控制須要使用下面指令來啓動行版本控制：

ALTER DATABASE   [databaseName] SET READ_COMMITTED_SNAPSHOT off;

或者

ALTER DATABASE [databaseName]  SET READ_COMMITTED_SNAPSHOT on  with rollback immediate

 

 

Read Committed Snapshot和Snapshot Isolation都是經過行版本控制來實現的；

SNAPSHOT快照：SNAPSHOT和READ COMMITTED SNAPSHOT兩種隔離（能夠把事務已經提交的行的上一版本保存在TEMPDB數據庫中）

SNAPSHOT隔離級別在邏輯上與SERIALIZABLE相似
READ COMMITTED SNAPSHOT隔離級別在邏輯上與 READ COMMITTED相似

 

不過在快照隔離級別下讀操做不須要申請得到共享鎖，因此即使是數據已經存在排他鎖也不影響讀操做。並且仍然能夠獲得和SERIALIZABLE與READ COMMITTED隔離級別相似的一致性；若是目前版本與預期的版本不一致，讀操做能夠從TEMPDB中獲取預期的版本。

若是啓用任何一種基於快照的隔離級別，DELETE和UPDATE語句在作出修改前都會把行的當前版本複製到TEMPDB中，而INSERT語句不須要在TEMPDB中進行版本控制，由於此時尚未行的舊數據

不管啓用哪一種基於快照的隔離級別都會對更新和刪除操做產生性能的負面影響，可是有利於提升讀操做的性能由於讀操做不須要獲取共享鎖；

 

 

 

 

 

 

 

 

 

 

 

MVCC機制

 

 

MVCC

MVCC即多版本併發控制，使用了雙版本號來解決數據的隔離問題。（「create」一個版本號，「delete」一個版本號，修改操做拆分爲「delete」和「create」）每一個事務在開始對每張表增刪改查操做時都會生成一個版本號，每一個事務只能查到「create」小於本版本號和「delete」大於本版本號的數據。這樣，增刪查操做就徹底能夠併發進行了，只有修改操做是必定要排隊的。這樣，就算沒有共享鎖也解決了不可重複讀問題，由於其餘事務修改後，數據的版本號比我大，我不會讀到。