我花了很多时间为数据库管理员优化查询。当我在测试服务器和实时服务器中运行它时，我得到类似的结果。但是，一旦它在生产中实际运行并且查询被大量使用，它的运行就非常差。

我可以发布代码，但是查询超过1400行，并且要花费很多时间进行混淆。所有数据类型都匹配，并且我在查询中使用索引。它分为58个临时表。当我使用SQL Sentry测试它时，我使用707个CPU周期和90,0007次读取以及1.2秒的时间来运行特定的exec语句。上周在生产中使用相同的参数时，使用了10,831个CPU周期，读取了290万次读取，并且运行了33.9秒。

我的问题是，比起一次性测试，优化器在生产中运行更多的周期和读取数据的原因是什么？就像我提到的那样，如果需要，我可以发布代码，但是我正在寻找可以解决此类差异的答案。在我们的“计费”周期中，此特定过程会运行很多次，因此它每天要访问服务器数百次，而当月15日临近时，它将达到数千次。

谢谢

附录： 我知道如何优化查询，因为这是我工作的常规内容。正如我在评论中指出的那样，我的测试查询通常与实际生产没有很大差异。我不了解SQL Server方面的问题，想知道是否有一些事情我需要知道，当服务器负载较重时，这可能会影响我的查询。这可能不在本论坛的讨论范围之内，但是我认为我会向社区中的人们寻求帮助。

更新： 我仍在对此进行故障排除，只是回复一些评论。

一次测试与生产级别执行之间的执行计划是相同的。我正在与生产相同的环境，同一台服务器上进行测试。这是报告数据的过程。返回的数据，记录和命中的表都是相同的。我使用的参数与生产期间花费的天文数字处理时间相同，我正在做的事情与生产运行期间发生的事情之间的区别是服务器上的负载。并非所有的生产执行都花很长时间，绝大多数都在可接受的CPU和读取的阈值之内，当离群值有如此大的差异时，它是CPU的500倍和平均执行读取的150倍（即使相同的参数）。

我对服务器端的一切零控制。我只能控制proc的编码方式。我意识到我的proc很大，没有它，可能无法在这个论坛上得到一个好的答案。我还意识到，即使过程在此处发布，但由于过程的规模，我也不太可能获得良好的答案。

我只是在寻找洞察力，要看的事物的方向，并使用其他开发人员在处理类似问题时已经克服的问题的轶事证据。说明我的代码大小的注释是性能如此之高的原因，而很少需要该大小的代码则无济于事，并且坦率地说是无知的。我正在使用旧式C＃代码和一个处理数百万笔交易的数据库。在数十个相互连接的数据库中，成千上万张带有ERD的表会让您大吃一惊，我正在优化一场噩梦。就是说，我非常擅长，当我自己和数据库管理员对为什么我们看到如此惊人的数字感到困惑时，我想我会扩大自己的网络，看看这个更大的社区是否有任何想法。

下图是在15分钟的窗口中显示此过程的前32个执行的报告的图像。即使在前32名中，数字也不一致。下面的图像显示了我刚刚在同一服务器上运行的所有临时表和主查询中的第一个图像的＃1资源消耗。这些行是不同的临时表，底部是总和。总和显示在使用534个CPU和92,045次读取时运行1.5（1.492）秒。与昨天的33.9秒，10831个CPU和290万次读取相反：