数据库事务如何影响MSSQL Server的性能和吞吐量？

Question

目前，我们的服务器端平台每次有人调用Web方法时都会启动数据库事务，并在Web方法返回后提交它。所有Web服务都是事务性的，即使那些不更新数据库的Web服务也是如此。

此类决定对性能有何影响？如果我停止在不更新数据库的Web服务中使用事务，性能或数据库吞吐量会发生显着变化吗？

Answer 1

是的，这将特别有帮助，因为减少了由于未结交易引起的阻塞。但是，如果隔离级别不造成阻塞，则不会提高性能。 同样，在上述情况下如果存在性能问题，将不会影响吞吐量或资源使用，但会导致较高的锁使用/等待次数，从而导致阻塞。

Answer 2

简短回答

只要保证正确性就必须进行交易，但不再进行。

对于Web API中间层，通常明智的做法是将整个Web API方法封装到单个事务中，只要您确保非必要工作（例如调用外部服务或处理HTTP请求/响应）就可以了。在交易期限之外完成。

稍长的答案

在我所知道的所有关系DBMS中，您不能只是“关闭”事务。如果您未明确启动事务，则将为您隐式启动事务，并持续进行SQL查询。

因此，选择的不是要进行交易，而是要进行多长时间。换句话说，对于每个查询，您应该拥有一个单独的事务，还是要包含多个查询（以及几个）？这是特定于您要实现的逻辑 ¹ ，只有您可以在此处做出明确的决定。

长期交易会产生成本。例如，一个INSERT / UPDATE / DELETE查询可能在修改后的行上放置锁，然后可能迫使其他一些查询等待直到事务结束 ² 。显式锁（例如Oracle下的FOR UPDATE或SQL Server下的WITH(XLOCK)）也将保留到事务结束，效果类似。在这种情况下，交易越早结束，被阻止的交易就越可以继续其工作。

此外，您应始终尝试在事务处理期间内尽量减少不必要的工作。例如：

• 避免在事务期间调用外部服务-您不想在等待缓慢响应（或更糟糕的是：网络超时）时阻止其他事务。 ³
• 应该在开始事务之前解析HTTP请求，并在事务之后构造HTTP响应。

---

¹ 例如哪些修改集应该是原子的，或者哪些只读查询应该看到相同版本的数据（如果使用快照隔离级别）。

² 在某些情况下，编写者可以阻止读者，也可以仅阻止作家，也可以什么也不阻止。这在很大程度上取决于当前的事务隔离级别以及具体的DBMS实现。

³ 类似：避免在事务处理期间等待UI输入-您不想在等待用户单击按钮时阻止其他事务处理（不适用于Web中间层） ，但我看到桌面应用程序正在执行此操作。