目前，我们的服务器端平台每次有人调用Web方法时都会启动数据库事务，并在Web方法返回后提交它。所有Web服务都是事务性的，即使是那些不更新数据库的Web服务也是如此。
这种决定对业绩有何影响？如果我停止在不更新数据库的Web服务中使用事务，性能或数据库吞吐量会显着变化吗？
是的，它会有所帮助，特别是由于公开交易造成的封锁减少。但是，如果隔离级别不会产生阻塞，则不会有性能提升。此外，如果在上述场景中存在性能问题，也不会影响吞吐量或资源使用，但会导致高锁定使用/等待，从而导致阻塞。
只要你必须保证正确，就进行交易，但不能再做。
对于Web API中间层，将整个Web API方法封装到单个事务中通常是明智的，只要您确保非必要工作（例如调用外部服务或处理HTTP请求/响应）是在交易的持续时间。
在我所知道的所有关系DBMS中，你不能只是“关闭”交易。如果您没有显式启动事务，它将隐式启动并持续SQL查询的持续时间。
因此，选择的不是是否进行交易，而是应该进行多长时间。换句话说，您是否应该为每个查询分别设置一个事务，或者包含多个查询（以及多少个查询）？这特定于您尝试实现的逻辑1，只有您可以在此处做出明确的决定。
与长期交易相关的成本。例如，INSERT / UPDATE / DELETE查询可能会在已修改的行上放置锁定，然后可能会强制某些其他查询等到事务结束2。显式锁（例如Oracle下的FOR UPDATE或SQL Server下的WITH(XLOCK)）也将保留到事务结束，具有类似的效果。在这种情况下，交易越早结束，它阻止的交易越早就能继续进行。
此外，您应该始终尽量减少交易期间内的非必要工作。例如：
1例如哪些修改应该是原子的，或哪些只读查询应该看到相同版本的数据（如果您使用的是快照隔离级别）。
2在某些情况下，编写者可以阻止读者，或者只阻止编写者，或者根本不阻止编写者。这高度依赖于当前的事务隔离级别和具体的DBMS实现。
3以类似的方式：避免在事务期间等待UI输入 - 您不希望在等待用户单击按钮时阻止其他事务（不是真正适用于Web中间层，但我看到桌面应用程序正在执行此操作）。