增加访问 SQL Server 的次数会损失多少性能？答案

【问题标题】：How much performance do I lose by increasing the number of trips to SQL Server?增加访问 SQL Server 的次数会损失多少性能？
【发布时间】：2010-07-15 14:11:40
【问题描述】：

我有一个 Web 应用程序，其中 Web 服务器和 SQL Server 2008 数据库位于同一服务器场中的不同机器上。

如果我将一个单一的存储过程分解为几个较小的存储过程，从而使客户端代码负责调用多个存储过程而不仅仅是一个，我会注意到在我的网络应用程序？

其他背景信息：

我有一个包含数百行代码的存储过程，其中包含决策逻辑、更新语句，最后是一个将一组数据返回给客户端的选择语句。

我需要在调用组件 DLL 的客户端代码（从这个意义上说，客户端代码是调用数据库服务器的 ASP Web 服务器）中插入一个功能。但是，存储过程正在更新记录集并在同一调用中返回更新的数据，理想情况下，我的代码需要在调用决策逻辑和更新语句之后调用，但之前 /em> 数据返回给客户端。

为了让这个功能发挥作用，我可能不得不将现有的存储过程分成至少两部分：一个更新数据库的存储过程，另一个从数据库中检索数据的存储过程。然后我会在这些存储的过程调用之间插入我的新代码。

当我看到这个问题时，我不禁认为，从代码维护的角度来看，将我的更新和select语句隔离所有会更好存储过程并将业务逻辑留给客户端代码。这样，每当我需要在客户端代码中插入功能或决策逻辑时，我所需要做的就是更改客户端代码，而不是修改一个巨大的存储过程。

虽然从代码维护的角度来看，使用精简存储过程可能会更好，但是通过增加访问数据库的次数我会遇到多大的性能问题？数据的最终结果是相同的，但我更频繁地接触数据库。当扩展应用程序以满足需求时，这种方法对性能有何影响？

我不是一个将性能优化置于一切之上的人，尤其是当它影响代码维护时，但我不想在 Web 应用程序必须扩展时自责并造成头痛。

【问题讨论】：

标签： sql-server performance stored-procedures code-maintainability

【解决方案1】：

一般来说，根据经验，您应该至少往返 SQL Server。

服务器上的“命中”非常昂贵，实际上将相同的操作分成 3 个部分然后在服务器上进行 1 次命中和其他所有操作的成本更高。

关于维护，您可以从客户端调用 1 个存储的 proc，让该 proc 调用另外 2 个 proc。

我有一个具有极端搜索逻辑的应用程序，这就是我为实现它所做的。

一些基准测试结果... 前段时间我有一个客户端，它的服务器出现故障并崩溃，当我们检查问题时，它是多次往返 SQL 服务器，当我们最小化它时，服务器恢复正常。

【讨论】：

【解决方案2】：

它会影响它。我们使用 Weblogic 服务器，其中所有业务逻辑都在连接到 DB/2 数据库的 AppServer 中。我们在我们的项目中主要使用实体 bean，并且对于大多数业务服务调用会多次访问数据库而没有明显的副作用。（我们会在需要时将一些查询调整为多表）。

这真的取决于您的应用。您将需要进行基准测试。

【讨论】：

【解决方案3】：

在良好硬件上设置良好的 SQL Server 每秒可以处理数千个事务。

事实上，分解一个大型存储过程可能是有益的，因为每个批次只能有一个缓存查询计划。分成几个批次意味着他们每个人都会得到自己的查询计划。

您绝对应该在代码维护方面犯错，但要确定基准。

鉴于查询计划格局将发生变化，您还应该准备好更新索引，可能会创建不同的覆盖索引。

【讨论】：

【解决方案4】：

本质上，这个问题与紧耦合与松耦合密切相关。

一开始：你总是可以把单体存储过程分解成几个较小的存储过程，它们都被一个存储过程调用，这样就可以让客户端代码只负责调用一个存储过程。

除非客户端会做某事（更改数据或向用户提供状态），否则我可能不建议将多个调用移动到客户端，因为您会将客户端更紧密地耦合到存储过程的操作顺序，而无需显着的性能提升。

无论哪种方式，我都会对其进行基准测试并从那里进行调整。

【讨论】：