事务中的加锁顺序问题

事务中的加锁顺序问题

事务中分有4中级别的

下面直接引联机帮助

SET TRANSACTION ISOLATION LEVEL

{ READ COMMITTED

| READ UNCOMMITTED

| REPEATABLE READ

| SERIALIZABLE

}

参数

READ COMMITTED

指定在读取数据时控制共享锁以避免脏读，但数据可在事务结束前更改，从而产生不可重复读取或幻像数据。该选项是 SQL Server 的默认值。

READ UNCOMMITTED

执行脏读或 0 级隔离锁定，这表示不发出共享锁，也不接受排它锁。当设置该选项时，可以对数据执行未提交读或脏读；在事务结束前可以更改数据内的数值，行也可以出现在数据集中或从数据集消失。该选项的作用与在事务内所有语句中的所有表上设置 NOLOCK 相同。这是四个隔离级别中限制最小的级别。

REPEATABLE READ

锁定查询中使用的所有数据以防止其他用户更新数据，但是其他用户可以将新的幻像行插入数据集，且幻像行包括在当前事务的后续读取中。因为并发低于默认隔离级别，所以应只在必要时才使用该选项。

SERIALIZABLE

在数据集上放置一个范围锁，以防止其他用户在事务完成之前更新数据集或将行插入数据集内。这是四个隔离级别中限制最大的级别。因为并发级别较低，所以应只在必要时才使用该选项。该选项的作用与在事务内所有 SELECT 语句中的所有表上设置 HOLDLOCK 相同。

－－－－－－－－－－－－－－－－－－－－－

这4中级别只有READ UNCOMMITTED是

可以做到无论排他锁还是共享锁都仅仅是在执行完sql语句后就释放锁，

READ COMMITTED针对排他锁而言必须要等事务完成后才能释放排他锁（排除锁转换）

后两种是无论是共享还是排他锁都一直持有，知道事务结束。

因此就并发性来说READ UNCOMMITTED是最好的，但他能造成很严重的脏读，因此微软

的默认的事务级别为READ COMMITTED