重构存储过程

Question

我有一个存储过程当前正在执行一个复杂的提取，在使用时经常超时。我部门提出的解决方案就是简单地增加超时时间长度;我真的不想这样做。我想重构这个sproc，但因为它太复杂而且没有文档（yay遗留系统）我担心我的重构不会导致相同的功能更有效地执行。在重构存储过程时是否有任何策略可以确保在更短的时间内执行相同的功能？

这是Microsoft SQL Server 2005存储过程。

Answer 1

过去我一直面对这种情况。最好的办法是创建一个简单的C＃或VB .Net应用程序。当你重构sp时，给它一个新的名字。使用该应用程序调用旧的和新的sp。然后比较两个sp的输出，以确保它们以相同的顺序返回完全相同的值。

您可能希望尽可能多地测试各种输入参数，以确保您的重构没有修改业务逻辑。

此外，使用NUnit可以帮助简化此任务。

当我开始当前职位时，我获得了一个必须针对新架构进行修改的数据库。它需要改变超过100 sp。使用我所描述的应用程序，我能够合理地确定我的一个修改没有破坏业务规则。

你是对的，只是增加超时是错误的第一个答案。尽可能地改进sp，然后在必要时增加超时。

Answer 2

通常，单个SQL语句会发生超时。将proc分解为单独的语句，可能通过有效使用临时表，因此您不会尝试在单个块中执行太多操作。通过这样做，您还可以了解性能瓶颈，并在需要时识别一些有用的索引。

Answer 3

我遇到的低效存储过程的最常见原因是标量类型操作的普遍存在，而不是基于集合的操作。大多数RDBMS系统（Oracle，SQL Server，MySQL等）在处理大型数据集时效率更高，而不是多次重复执行单个操作。对一百万行数据执行一次操作比在每行执行一百万次操作更有效。

在尝试确定这些类型的瓶颈（通常首先查看函数调用）后，我建议您查看您引用的表上的索引策略。根据您选择的RDBMS，您可能具有一些向导类型的功能，可以帮助您根据示例工作负载发现正确的索引结构。

您使用的数据库是什么？这可能有助于微调我的一些建议。

Answer 4

使用SQL Server Profiler来研究当前SP的运行方式;它将突出低效率，并允许您开始只针对那些特定区域，同时留下更高性能的位。然后，您可以在修订后的SP上再次使用分析器来比较性能。

我会回应Gunny的建议，好好看一下函数调用 - 在基于集合的操作中，这些可以对性能产生实际影响。过去只通过剥离单个UDF并复制内联逻辑，我已经取得了巨大的性能提升。