Read Committed级别下，修改数据获得的x锁何时释放

Question

数据事务

Answer 1

仔细分析一下就知道第二种说法明显是错误的，Read Committed避免脏读这一点是没有疑问的，
那么，
事物没有提交之前的INSERT、DELETE、UPDATE是不是脏数据呢，如果事物没有提交（这些操作）就释放X锁，
因为没有了排他锁，这些未提交的数据是不是能被其他会话读取到
这不是不是就冲突了呢修改数据的X锁，肯定是到这个事物的结束才释放的

Answer 2

第二种说法是错误的。在read committed隔离级别下，读取数据时获得S锁，在读完后会立即释放s锁，而对于 INSERT、DELETE、UPDATE的执行，获得X锁，并持有至事务结束。

Answer 3

我觉得你最好是对整个锁有一个全面的了解，关于锁，有如下的几个方面：1、锁的模式，指定你要加的是什么类型的锁，比如读还是写：比如有 s，x，u，is，iu，ix，six等等2、锁的粒度，制定了你要锁定的范围：行锁或key锁，页锁，allocation unit锁，对象锁，数据库锁3、锁的兼容性，就是比如s和u是兼容的，而s，u 和 x是不兼容的，不兼容，那么就会导致后申请锁的会话等待4、事务隔离级别，控制事务之间的相互影响程度，比如你是read uncommitted，那么select语句在执行时，就会去获取s锁，所以也就不可能会被其他会话阻塞，但是insert，update，delete还是还是会获取x锁，因为整个是保证数据一致性的基本要求。另外，在2005以后，提出了快照整个概念，比如你可以修改数据库的属性：read_committed_snapshot 为 on，这样就可以实现读操作和写操作，互不阻塞了。综上所述，还是会有很多方面需要你去探索和理解的。另外，如果是oracle就完全和sql server不一样了，但理解了sql server的锁机制，对于你以后理解oracle的锁机制，应该是有很大帮助的

Answer 4

Read Committed级别，读取数据时不能获取X锁
所以第二点描述没啥问题吧，只有INSERT,UPDATE和DELETE提交后才能读取。
不知道各位大师如何见解！

Answer 5

话说，上次你提到的那个分页性能优化的问题，你找到相关的资料了吗
没有，之前测试的情况比较简单，就是2,3张表关联，比较row_number和rownum分页，那次是生产环境的sql，涉及到一些聚合运算之类的操作，特意比较了一下，两种方式，测试结果是rownum明显占优，我怀疑是某些运算（聚合）之类的造成的

Answer 6

话说，上次你提到的那个分页性能优化的问题，你找到相关的资料了吗
没有，之前测试的情况比较简单，就是2,3张表关联，比较row_number和rownum分页，那次是生产环境的sql，涉及到一些聚合运算之类的操作，特意比较了一下，两种方式，测试结果是rownum明显占优，我怀疑是某些运算（聚合）之类的造成的你看了执行计划有什么大的不同了吗

Answer 7

读取数据只到事务结束才释放要repeatable read 才可以。read committed是语句结束就释放。不到事务结束。
有时候甚至是边读取 边释放。
建议楼主看下T-SQL语言基础。第9张 讲的很清楚

Answer 8

话说，上次你提到的那个分页性能优化的问题，你找到相关的资料了吗
没有，之前测试的情况比较简单，就是2,3张表关联，比较row_number和rownum分页，那次是生产环境的sql，涉及到一些聚合运算之类的操作，特意比较了一下，两种方式，测试结果是rownum明显占优，我怀疑是某些运算（聚合）之类的造成的你看了执行计划有什么大的不同了吗查询结果是一样的，sql结构些差异，
row_number的方式计划比较直接，就是全表扫描+hashjoin
rownum的计划比较复杂了