SQL Server执行普通SELECT报快照隔离事务失败报错咨询

首先明确一个常见误区：就算没有写BEGIN TRANSACTION显式开启事务，单条SELECT语句也会运行在隐式事务上下文中。SQL Server默认开启自动提交模式，单条语句的整个执行周期本身就是一个独立事务，在SNAPSHOT隔离级别下，这个隐式事务的一致性快照起点就是语句开始执行的瞬间，快照隔离的所有约束规则对它完全生效。

你碰到的报错和普通行数据的读写锁冲突无关，本质是快照隔离的设计边界：

SQL Server的快照隔离机制仅对用户表的业务行数据做版本存储，系统表中的对象元数据不支持版本控制。

从隐式快照事务（也就是你的单条SELECT）启动开始，只要有其他并发会话对查询访问的表、关联索引/视图等对象执行了任意DDL操作（包括修改字段定义、增删约束、创建/重建索引、调整表结构等），SQL Server检测到元数据版本高于事务启动时的版本，就会直接抛出该错误。这是强制的保护逻辑：没有历史元数据版本可以回溯的前提下，继续执行查询可能返回结构不一致的错乱结果，因此直接阻断执行，和操作是读还是写、是否手动开启显式事务没有关联。

不需要在每次执行查询前手动切换隔离级别到READ COMMITTED，根据实际场景选择对应方案即可：

• 优先开启数据库级别的READ_COMMITTED_SNAPSHOT选项，用读提交快照隔离（RCSI）替代会话/全局级别的SNAPSHOT隔离。RCSI是语句级别的行版本控制，一致性快照在单条语句启动时才生成，既可以实现读写互不阻塞，又大幅缩短了元数据一致性校验的时间窗口，是绝大多数OLTP业务场景的推荐配置。开启该选项后，默认的READ COMMITTED隔离级别会自动使用行版本读取，无需每次执行语句前手动修改隔离级别设置。
• 如果业务场景确实需要使用事务级别的SNAPSHOT隔离，直接为查询添加瞬时错误重试逻辑即可。该报错属于可重试的临时错误，重试时会启动新的隐式事务、加载最新版本的元数据，通常重试1-2次即可正常执行。
• 如果环境内存在定时DDL任务（比如定时索引重建、表结构版本发布），尽量将这类任务调度到业务低峰期执行，从根源上降低DDL和业务查询并发冲突的概率。
• 避免在SNAPSHOT隔离级别下执行长事务，事务持续的时间窗口越长，执行期间碰到并发DDL修改元数据的概率就越高。

内容的提问来源于stack exchange，提问作者Mark Morrisson