1

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

如果我采用一个整体存储过程并将其分解为几个较小的存储过程，从而使客户端代码负责调用多个存储过程而不仅仅是一个，我会注意到我的 Web 应用程序的性能会受到显着影响吗？

附加背景信息：

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

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

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

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

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

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

4

4 回答 4

1

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

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

于 2010-07-15T14:18:12.723 回答
1

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

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

您绝对应该在代码维护方面犯错，但可以肯定的是基准测试。

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

于 2010-07-15T14:18:13.663 回答
1

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

一开始：你总是可以把单体存储过程分解成几个更小的存储过程，这些存储过程都由一个存储过程调用，从而使客户端代码只负责调用一个存储过程。

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

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

于 2010-07-15T14:20:53.800 回答
1

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

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

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

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

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

于 2010-07-15T14:21:50.857 回答