SQL Server 通过启用 READ COMMITTED SNAPSHOT（RCSI）实现并发快照读，使所有 SELECT（含 JOIN、子查询、CTE）自动读取事务开始时的已提交版本，避免阻塞；但依赖 tempdb 性能与空间、数据库级启用 RCSI 及连接列索引。
SQL Server 本身不提供“并发快照读取”这个独立功能，但你可以通过 SNAPSHOT 隔离级别 + 合理的 JOIN 设计，实现近似效果：即在高并发下避免阻塞、读取事务一致的旧版本数据。关键不是 JOIN 本身，而是隔离级别与 JOIN 执行方式的配合。
为什么不能靠 JOIN 实现快照读？
JOIN 是数据组合逻辑，不控制版本或锁行为；真正决定是否读取历史版本的是事务隔离级别。默认的 READ COMMITTED 会加共享锁并等待写入释放，而 SNAPSHOT 隔离级别才启用行版本控制（tempdb 中的 version store），让 SELECT（含所有 JOIN）自动读取事务开始时刻的已提交快照。
- 即使写复杂
INNER JOIN或LEFT JOIN，若未开启快照隔离，照样可能被阻塞 -
SNAPSHOT对所有读操作透明生效，包括JOIN、子查询、CTE —— 不需要改 SQL 写法 - 注意：
READ COMMITTED SNAPSHOT（RCSI）更常用，它修改的是默认行为，而SNAPSHOT需显式SET TRANSACTION ISOLATION LEVEL SNAPSHOT
启用 RCSI 后 JOIN 查询的实际表现
开启 READ COMMITTED SNAPSHOT 后，所有普通 SELECT（含任何 JOIN）自动读取版本化快照，不再申请共享锁，也就不会与写操作冲突。但 JOIN 本身的执行效率仍取决于底层 join 算法和索引：
- 小表驱动大表时，
Nested Loops Join依然高效；若两表都大且连接列有排序索引，SQL Server 可能选Merge Join，此时 RCSI 不影响其 O(M+N) 复杂度优势 - 若连接列无索引，
Hash Join可能被选中，但 hash 构建过程仍需内存和 tempdb，RCSI 不缓解这部分开销 -
LEFT JOIN在 RCSI 下同样无阻塞，但若右表匹配行极少，仍可能因大量 NULL 补充导致逻辑读上升
容易被忽略的三个硬性依赖
RCSI 不是开关一开就万事大吉，以下三点任一缺失都会让快照读失效或性能崩溃：
-
tempdb必须足够快且有充足空间：所有行版本都存在tempdb的 version store 中，IO 瓶颈或空间不足会导致语句失败或回退到锁模式 - 必须在数据库级启用：
ALTER DATABASE [YourDB] SET READ_COMMITTED_SNAPSHOT ON；仅改会话隔离级别（如SET TRANSACTION ISOLATION LEVEL SNAPSHOT）不够，且要求数据库已开启ALLOW_SNAPSHOT_ISOLATION - JOIN 条件字段必须有索引：否则即使不阻塞，全表扫描 + 版本查找也会拖慢响应，尤其在高并发下放大
tempdb压力
真正卡住并发快照读的，往往不是 JOIN 写法，而是 tempdb 配置、索引缺失或未正确启用 RCSI —— 这些比纠结用 INNER 还是 LEFT 关键得多。
