sql锁

　①脏读：事务A读到事务B尚未提交的数据，并基于这个数据进行后续操作

　　②不可重复读：事务A读取数据后，被事务B修改或删除，事务A再次读取时前后两次读取的数据不一致

　　③幻像读：事务A读取数据后，事务B新增了数据，事务A再次读取是前后两次读取的数据不一致 

 

 

   1 ：ReadUncommitted,可以进行脏读，即使一项操作未做完或未提交，其他操作也可以读取未提交的数据。

2： ReadCommitted,它是SQLServer的默认隔离级别，此级别可确保只有在第一个事务提交之后，第二个事务才能读取第一个事务操作后的数据，从而避免数据的脏读，增强了数据安全性

3：RepeatableRead,这个级别扩展了ReadCommitted级别，即对正在访问的数据加上放置锁，其他操作将不能修改这些数据，确保数据的可重复读取，但是其他操作可以添加数据

4 ：Serilizable,这是最高的事务处理级别，它将阻止修改本事务所查询的数据的任何操作，由于对正在访问的数据加了额外的锁定，因此将会降低整个数据操作性能

ReadCommitted,的X锁会保留到事务结束，select 很快会被柿放。

因为REPEATABLE READ隔离级别下的共享锁保留到事务结束.

在数据库中有两种基本的锁类型：排它锁（Exclusive Locks，即X锁）和共享锁（Share Locks，即S锁）。当数据对象被加上排它锁时，其他的事务不能对它读取和修改。加了共享锁的数据对象可以被其他事务读取，但不能修改。数据库利用这两种基本的锁类型来对数据库的事务进行并发控制。 

死锁的第一种情况 

一个用户A 访问表A(锁住了表A),然后又访问表B；另一个用户B 访问表B(锁住了表B)，然后企图访问表A；这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B才能继续，同样用户B要等用户A释放表A才能继续，这就死锁就产生了。 

假设上面表 A 和表 B 都有IDENTITY自增域，那么我们在表 A 插入一条数据后，使用了 

SELECT @@IDENTITY 输出时，输出的到底是 A 还是 B 的自增域的值呢？ 答案很明显，是谁最后插入就输出谁，

那么就是 B 了。于是，我本意是想得到 A 的自增域值，结果得到了 B 的自增域值，一只 BUG 随之诞生，搞不好还

会影响到整个系统数据的混乱。

因此，对于这种情况，建议大家慎用 @@IDENTITY，而尽量采用 SCOPE_IDENTITY() 函数替换之。SCOPE_IDENTITY() 

也是得到最后一条自增域的值，但是它是仅限在一个操作范围之内，而不像 @@IDENTITY 是取全局操作的最后一步操作

所产生的自增域的值的。