我已经编写了一个存储过程，从Management Studio执行时需要 15分钟。但是，当它从Service Broker激活时，在 4小时之后，它甚至没有完成一半的工作。
从Service Broker运行SP时是否存在已知的性能问题？ （也许Service Broker在事务中运行SP而Management Studio不运行？）
我正在使用SQL Server 2005。
更新
问题似乎是从另一个存储过程执行存储过程。更具体地说，我有一个存储过程接收操作（导出或删除）。然后，该SP基于操作调用相应的SP（一个具有ETL过程，另一个具有删除数据）。强制重新编译这些SP似乎已经解决了这个问题。我想知道SQL Server是否应该为每个子SP制定一个行动计划，独立于调用它们的SP。在这种情况下，不需要重新编译。
答案 0 :(得分：1)
我不了解Service Broker，但对于一般存储过程的疑难解答，请查看this question中给出的建议。他们帮我解决了存储过程中的一些问题。
您可以查看存储过程使用WhoIsActive例程执行的操作，您可以获取查询计划并研究在Management Studio中执行时是否与查询计划有任何差异，您可以试验{{ 1}}提示消除参数嗅探...
（参数嗅探是在提供其他参数时生成不同的查询计划.Service Broker是否将与您在Management Studio中传递的参数相同的参数传递给SP？）
祝您好运，如果您不成功，请在此发布您的发现。