数据库 事物 锁

事物中的锁简单说就是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”大于本版本号的数据。这样，增删查操做就彻底能够并发进行了，只有修改操做是必定要排队的。这样，就算没有共享锁也解决了不可重复读问题，由于其余事务修改后，数据的版本号比我大，我不会读到。