而在MSSQL中，也是通过锁和MVCC的行版本来实现并发控制。

    每个事务中，锁的类型、级别、加锁、释放的情况，由事务的隔离级别控制，在MSSQL中，有6个隔离级别，不同的隔离级别对锁的应用不一样。而这两个隔离级别中，有2个应用 MVCC的机制，也就是 快照类的隔离级别：Read Commmitted Snapshot 跟 Snapshot。

    在MSSQL中，经常用到的并发控制理论是 悲观并发控制跟乐观并发控制。

    悲观并发，默认在事务操作过程中，一定会有其他事务跟它争夺资源，所以在事务操作过程中，会根据不同的情况对数据添加锁，避免操作期间其他事务对该数据的修改或读取，保证数据的一致性。

    悲观并发控制，由于纳入了锁机制，很大程度会影响到并发规模。主要应用于数据频繁修改、并且回滚事务的成本要大于锁数据的成本 的系统中。

    乐观控制，默认事务在读取数据的时候，其他事务并没有在操作这些数据，所以不会加锁，直接修改数据，修改后查看读取数据期间是否有其他用户也修改了数据，如果有，则回滚本身的修改事务。

    乐观并发控制，应用于数据修改不频繁、并且 回滚事务成本要小于锁数据成本 的系统中。 

    在每一个事务中，都指定了一个隔离级别，该隔离级别定义了这个事务跟其他事务之间的隔离程度。

 

    在MSSQL中，有6种隔离级别，4个常规隔离级别跟2个快照隔离级别：Read UnCommitted、Read Committed、Read Commmitted (行版本)、Read Repeattable、Snapshot跟Read Serializeble。Read Commmitted (行版本)跟Snapshot 可能接触情况比较少，不过仍会说明。

 

    在MySQL中，默认的隔离级别是RR，而在SQL SERVER中，默认的隔离级别是RC，读已提交。

    如何设置整个数据库的默认隔离级别？   

 

    数据不一致的说明详见之前博文：http://www.cnblogs.com/xinysu/p/7260227.html 中的第四章：数据不一致情况。

 

    下文中说S锁，并不是全部加锁过程（MSSQL中还是IS锁的申请）。

    Read Commmitted Snapshot Isolation 使用行版本控制语句级的快照，在事务中当数据发生修改或者删除时，调用写入复制机制，保证写入的行数据的旧版本满足事务操作前的一致性。 RCSI 保证的是语句级的 读一致性。

    Snapshot Isolation 使用行版本控制事务级的快照，当事务开始的时候，调用写入复制机制。 SI 保证的是事务级 的读取一致性。

         

     如何管理行版本信息呢？

     两者的行版本的信息均存储在tempdb数据库内，并非存储在本身的数据库，这就要求tempdb要有足够的空间存储版本信息，如果tempdb空间不足，则行版本写入失败，造成该隔离级别无法正常使用。

     存储引擎对使用 RCSI 或者 SI 隔离级别的事务，在 SI事务开始的时候，分配一个事务序列号 XLN，每次分配递增1，以此实现事务级的一致性，这里注意 RCSI的 事务序列号 并不是一个事务一个序列号，而是事务内每条SQL一个事务序列号，以此来实现语句级别的快照。这两个隔离级别下，需要维护所有执行过数据修改的逻辑副本（即行版本），这些逻辑副本存储在tempdb内，每个逻辑副本（行版本）都有标记本次的事务的事务序列号XLN。即 最新的行值存储在当前的数据库中，而历史行版本信息包括最新版本，存储在tempdb中。这里注意一下，事务内的修改数据写行版本信息的时候，先写入到缓存池中，在刷新到tempdb文件，避免性能造成太大的影响。

    

    这个时候，可能会问？那岂不是tempdb要存储非常多的历史版本数据，有没有删除机制呢？

    这个是有的，一方面，行版本信息不会即时删除，因为要保证基于行版本控制隔离级别下运行的事务要求，保证并行的事务如果正在使用tempdb的行版本信息 不会受到影响。另一方面，数据库的存储引擎 会跟踪最早可用的事务序列号，然后定期删除比序列号更小的 XLN的所有行版本。

      

      如何读取行版本信息呢？

      两个快照隔离级别下的 的事务读数据的时候，不会获取正在读取数据上的共享锁，因此不会堵塞正在修改的事务，由于减少了锁的申请及数量，可以提供其DB并发能力。不过会获取所在表格的架构锁，如果表格正在发现架构修改（如列增加修改等），则会被堵塞。

      如何读取合适的行版本，RCSI 跟 SI 之间是有区别的。

      RCSI：每次启动语句时，提交所有数据，同时读取tempdb中的最新事务序列，这使 RCSI 下事务内的每个语句 都可以查看每个语句启动时存在的最新数据的快照，也就是 事务内多个SQL查询间隙中有其他事务修改了数据，那么同个事务的多次相同SQL查询结果就会出现不一致的情况。

      SI：每次启动事务时，提交所有数据，读取 最接近但低于 本身的 快照事务序列号，也就是 事务内的多个SQL 查询，读到的数据都是同一个版本，即使多次查询间隙有其他事务修改数据，读到的结果也是一致的。

 

      如何修改行版本信息呢 ？

      在使用 RCSI 事务中，使用阻塞性扫描（其中读取数据值时将在数据行上采用更新锁（U 锁）完成选择要更新的行，满足条件的行记录将升级更新锁到排它锁，注意，这里扫描的不是tempdb里边的行版本信息，而是实际数据库里边的最新行记录，修改数据的机制跟 RC 相同。 如果数据行不符合更新条件，则在该行上将释放更新锁，同时锁定下一行并对其进行扫描。持有锁之后，则进行数据更新，事务结束后，释放锁。

 

      在使用 SI 事务中，对数据修改采用乐观方法：使用行版本的数据，进行数据修改，直到数据修改完成是，才获取实际数据上的锁， 当数据行符合更新标准时，则提交修改的数据行。 如果数据行已在快照事务以外修改，则将出现更新冲突，同时快照事务也将终止。 更新冲突由数据库引擎处理，无法禁用更新冲突检测。

 

      从简单的SQL来分析，WHERE条件均为主键（仅为个人测试推测）：

• 同个事务，多次 SELECT  * FROM tbname WHERE id=2
• RCSI，在同个事务中，每个SQL启动的时候，提交数据到tempdb表格（个人推测，应该是会分配一个类似hash字符串之类的，如果同个事务中的多次查询结果一致，应该不用在每个SQL开始的时候，重复提交行版本到tempdb），从tempdb中读取最新版本信息，如果tempdb没有版本信息，则从 数据库中读取，并把读取到的记录存储在 tempdb。会存在同个事务中，多次读取数据结果不一致的情况。
• SI，在同个事务中，同个事务内的相同SQL 从tempdb中读取距离当前事务最新的版本，整个事务内部的SQL都是用这个版本数据，如果tempdb没有版本信息，则从 数据库中读取，并把读取到的记录存储在 tempdb。同个事务中，不会存在 多次读取数据结果不一致的情况。
• UPDATE tbname SET colname='xinysu' WHERE id=18
• RCSI，直接读取数据库中的数据，根据主键加上X锁，更新数据，这个操作跟 RC 隔离级别是一样的。
• SI，读取 行版本 数据，在行版本上选择需要更新的行，修改成功后把数据 修改到实际的数据库中去，如果 实际数据库中的数据在这段操作期间已被其他事务修改了数值，则会出现更新冲突，该事务将报错停止。即，SI 在 UPDATE 的时候，有更新冲突检测。
• 为啥要先在行版本上更新，最后在更新到实际数据上？
• 假设一个UPDATE运行需要3s，但是只更新了1条行记录，如果直接在实际数据上更新，则需要锁定扫描记录3s，最后更新，中间会堵塞到其他事务对该数据的查询，但是如果在行版本上更新，则不需要锁住 实际数据，最后更新1行记录的时候，非常快，避免长时间的堵塞，提高并发能力。

注：本文内容来自互联网，旨在为开发者提供分享、交流的平台。如有涉及文章版权等事宜，请你联系站长进行处理。