READ COMMITTED隔离级下三类事务并发场景的疑问

针对READ COMMITTED隔离级的三个疑问，结合SQL Server的实际行为解答如下：

• *疑问1：当已执行插入、更新操作的update-transaction仍在运行时，启动select-transaction执行SELECT 是否会因不愿返回未提交数据而阻塞？
  默认配置下（未开启READ_COMMITTED_SNAPSHOT），会阻塞。因为update事务对修改的行持有排他锁，而READ COMMITTED隔离级的select会对读取的行请求共享锁，排他锁与共享锁互斥，select会等待update事务提交或回滚后才能获取锁读取数据。若开启了READ_COMMITTED_SNAPSHOT数据库选项，select会读取行的提交版本（快照），不会被阻塞，也不会读取未提交数据。

• 疑问2：若先启动需耗时1分钟的百万行表SELECT查询（select-transaction），之后启动update-transaction执行插入、更新，后者是否会被阻塞？
  默认配置下，是否阻塞取决于update要修改的行是否正被select读取：

  • 如果select还没扫描到目标行，update可以立即获取排他锁执行，不会被阻塞；
  • 如果select正在读取目标行（持有共享锁），update会被阻塞，直到select读完该行并释放共享锁（READ COMMITTED的共享锁是读完行就释放，而非持有整个事务周期）。
    若开启READ_COMMITTED_SNAPSHOT，select不会持有任何共享锁，update完全不会被阻塞，可直接执行。

• 疑问3：若update-transaction未被阻塞且在select运行期间提交，select会返回提交后的值吗？
  分两种情况：

  • 默认锁机制下：会返回提交后的值。因为READ COMMITTED每次读取行时，都会检查该行的最新提交状态，只要update已提交，select后续扫描到该行时就会读取更新后的数据。
  • 开启READ_COMMITTED_SNAPSHOT后：不会返回提交后的值。此时select读取的是事务启动时刻的行快照，整个查询过程中只会使用这个快照版本，后续提交的更新不会被纳入查询结果。

内容的提问来源于stack exchange，提问作者Tommy Ls