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 是取全局操作的最后一步操作
所产生的自增域的值的。