Sql server 快照事务隔离级别：它真的能像广告中那样工作吗？

在高并发环境中使用它有什么问题吗？它真的像微软的广告那样有效吗？我正在使用SQLServer2005，我想听听那些正在/曾经在生产中使用它的应用程序上使用它的人的经验

---

快照隔离本身对我来说并不新鲜，因为我也开发/管理Firebird/Interbase-没有明确的锁定，所有工作都在行版本控制中…

我们在两台服务器上使用快照隔离，包括不断复制计费系统更新的高争用副本，每秒有几十个查询从中进行选择。在我们打开快照隔离之前，长时间运行的select查询经常会阻止计费数据复制，以至于由于单线程复制服务被阻止，复制副本会在一个小时或更长时间内过期

启用快照隔离后，问题立即自行解决—Select语句查看数据的最新内部一致版本，复制可以在后台继续。权衡的结果是，您选择的数据可能正在更新中，因此两个同时执行的Select语句可能会返回不同的数据，但作为对争用容忍度提高的交换，我们可以这样做

---

您是否有任何特别的问题，或者只是对其工作情况的总体感觉？

我们没有在生产中使用它，但由于快照存储在tempdb中，因此您需要关注tempdb的使用情况—文件大小、I/O请求等。基本上是总体感觉，因为我想建议将生产数据库设置为快照隔离。它有很多争用，并且经常受到阻塞和一些死锁的困扰。因为我已经知道在使用Firebird开发了一些应用程序后，它是多么的舒适，所有的东西都在记录版本控制下-我只想知道MS的实现是否良好。@Fabrico Araujo:我对它们的实现没有任何问题，我承认我没有接触过任何其他人的行版本控制，所以我没有比较的依据。我确实知道，使用read committed时存在严重的争用问题，启用快照隔离可以缓解这些问题，没有任何意外副作用的抱怨。