Sql Server 数据库事务与锁，同一事务更新又查询锁的变化，期望大家来解惑！

我有一个People表，有三行数据：

如果我们没详细了解数据库事务执行加锁的过程中，会不会有这样一个疑问：如下的这段 SQL 开启了事务，并且在事务中进行了更新和查询操作。

BEGIN TRAN 
	update People set Name='张三' where id=1;
	
	select * from People where id=1;
commit tran

我们知道sql server数据库的默认事务级别是READ COMMITTED（已提交的读取），我们再看一下已提交读事务隔离级别描述：

允许事务读取另一个事务以前读取（未修改）的数据，而不必等待第一个事务完成。 SQL Server数据库引擎将保留 (对所选数据) 获取的写入锁，直到事务结束，但读取锁将在执行 SELECT 操作后立即释放。 这是SQL Server数据库引擎默认级别。

那么我们在READ COMMITTED 隔离级别下更新People表数据库，按照这个逻辑在id=1的数据行上添加排它锁（X锁）并等到事务提交后才会释放锁。 但是事务继续执行查询，在READ COMMITTED隔离级别下 Select 会对查询数据施加共享锁（S锁）。因为有排它锁，所以查询无法获得共享锁需要等待排它锁释放，如果按照这个逻辑的话这个事务自身就死锁无法执行了。

但这个事务还是会正常执行完成，针对这个疑问，那么我们看下数据库的事务和锁：

数据库引擎隔离级别

ISO 标准定义了以下隔离级别，SQL Server数据库引擎支持所有这些隔离级别：

SQL Server数据库引擎使用不同的锁模式锁定资源，这些模式确定并发事务如何访问资源。

T-SQL 设置事务隔离级别，只对当前会话连接一直有效

SET TRANSACTION ISOLATION LEVEL
    { READ UNCOMMITTED
    | READ COMMITTED
    | REPEATABLE READ
    | SNAPSHOT
    | SERIALIZABLE
    }

锁模式

下表显示了SQL Server数据库引擎使用的资源锁模式。

锁兼容性

锁兼容性控制多个事务能否同时获取同一资源上的锁。 如果资源已被另一事务锁定，则仅当请求锁的模式与现有锁的模式相兼容时，才会授予新的锁请求。 如果请求锁的模式与现有锁的模式不兼容，则请求新锁的事务将等待释放现有锁或等待锁超时间隔过期。 例如，没有与排他锁兼容的锁模式。 如果具有排他锁（X 锁），则在释放排他锁（X 锁）之前，其他事务均无法获取该资源的任何类型（共享、更新或排他）的锁。 另一种情况是，如果共享锁（S 锁）已应用到资源，则即使第一个事务尚未完成，其他事务也可以获取该项的共享锁或更新锁（U 锁）。 但是，在释放共享锁之前，其他事务无法获取排他锁。

下表显示了最常见的锁模式的兼容性。

查看执行时锁的情况

通过锁的兼容性模式我们知道在id=1的行上添加了排它锁，那么它就无法再接收任何锁，那我们调试这个事务看看锁的情况。

我们调试到第3行，这个时候看下锁的情况，此时事务添加了key(行）排它锁X锁，page（页）和object（表）添加了意向排它锁IX锁。

SELECT 
resource_type,
resource_database_id,
resource_description,
request_mode,
request_type,
request_session_id,
request_owner_type,
request_owner_id,
lock_owner_address
FROM sys.dm_tran_locks where request_owner_type='transaction'

然后我们再继续调试到第4行，此时还没提交事务，排它锁X依然存在，但是没有S锁。

我们知道在读提交事务隔离级别下，S锁是使用完了就释放的，所以我们用SQL Server Profiler来监视下锁的情况，设置监控的项为lock，然后设置筛选条件。

上面我已经将 张三1 改为了 张三，我们再将 张三 改回 张三1，并启动监控。

BEGIN TRAN 
	update People set Name='张三1' where id=1;
	select * from People where id=1;
commit tran

可以看到事务 transactionid=30010685 的锁监控 :

• 首先申请IX更新意向锁(object,page) 准备更新，然后获得行上的X排它锁进行更新，更新后释放了行锁和page锁（EventClass= Lock:released,Mode=0-null）。
• 等查询时申请page页IS意向读取锁，并获得行S锁读取数据后释放行锁和page页锁。
• 最后还有几个顺序释放，依次是key、page、Object，这里恰好和上面调试还没提交事务时查询sys.dm_tran_locks的锁情况一样，也就是说事务提交后依次又进行了一遍释放。

通过上面我们得出结论，事务里面并不是取得了X锁要等事务结束后才释放，在事务执行过程中也是有释放的，只是事务还保持着对于锁在事务层面的记录，防止其它事务并发（这里是我推断的，没找到相关文献说明）。 所以事务是在锁上更宏观的逻辑隔离，事务隔离级别只是在业务上保证数据符合隔离级别预期，至于事务中如何控制锁是基于数据库内在设计，而不能通过事务的描述去推断锁过程。

我查阅网上很多博文和官方资料都是讲事务和锁概念，有时候结合两种也是模棱两可看不出什么强联系，没有讲事务执行过程中锁是如何变化的，不知道我这篇推论是否正确，欢迎指正。

再次验证

我将事务隔离级别设置为REPEATABLE READ（可重复读），然后调试到commit行还没提交，我们看跟踪的锁和事务锁表dm_tran_locks查询的结果，按照REPEATABLE READ描述，select查询的S锁会在事务提交后释放，我们看看截图情况

开启了SQL Server Profiler结果，查询id=3后S锁已经释放。

再查dm_tran_locks表，表中依然显示事务获取了S锁，并且 resource_description=98ec012aa510 资源描述和上面跟踪是对应的。

最后我们执行完调试，跟踪锁显示又按照顺序释放了一遍锁