调整 SQL Server答案

【问题标题】：Tuning up SQL Server调整 SQL Server
【发布时间】：2015-03-03 23:48:06
【问题描述】：

我正在使用 SQL Server 2008，我想调整所有需要很长时间的存储过程

每当我单独执行一个存储过程时，我都会很快得到结果..

每当我们为 100 个用户运行负载测试时，结果都非常糟糕。

我正在使用带有 SQL Server 2008 的 .NET 应用程序

有什么方法可以找出问题所在吗？

【问题讨论】：

我使用adam machanic压力工具测试sqlblog.com/blogs/adam_machanic/archive/2006/10/21/…，我们希望看到带有后执行计划的存储过程可能还有一些改进空间
对工具的请求明显偏离主题，所以我删除了该行。
好吧，找到并创建缺失的索引。设置隔离级别以禁用锁定行为，当您知道它是安全的时。创建覆盖索引、检查包含列、微调查询等。
如果您使用的是 UDF 或 CLR 函数 - 它们可能是问题所在。否则 - 设计数据库和查询。

标签： sql sql-server performance sql-server-2008

【解决方案1】：

如果代码在 SSMS 中运行良好，但在 .NET 中却没有，可能是由于参数嗅探。尝试将以下查询提示添加到每个 select 语句的末尾：

OPTION (RECOMPILE)

如果现在这为 SSMS 和 .NET 提供了相似的结果，则说明您进行了参数嗅探。解决此问题的一种方法是重新编译选项，如上所述。但是，这每次都会重新编译查询，这只能作为最后的手段。更好的方法是使用局部变量，因此在存储过程中，将参数重新分配给变量并在选择查询中使用它们，如下所示：

create proc myproc (@param1 int, @param2 varchar(20))
as

declare @var1 int
declare @var2 varchar(20)

set @var1 = @param1
set @var2 = @param2

select
   <columns>
from
   <table>
where
       <column x> = @var1
   And <column y> = @var2

还有其他使用查询提示的解决方法，如下所述：

http://blogs.msdn.com/b/turgays/archive/2013/09/10/parameter-sniffing-problem-and-workarounds.aspx

【讨论】：

【解决方案2】：

您必须从逻辑上解决这个问题，以找出问题所在，然后才能进行调整/优化/其他任何事情。

首先，确认问题实际上是数据库——它可能是 .Net 应用程序。在 .Net 应用程序上放置一个分析器，并检查它确实花时间处理数据库查询，并且问题不是应用程序代码。

接下来，在数据库服务器上运行性能监视器；检查内存、CPU、磁盘 I/O 和网络。如果其中任何一个峰值或始终保持在 100%，则您可能遇到了硬件瓶颈。升级硬件通常要便宜得多。当然，数据库问题很可能表现在 CPU 或内存峰值上，所以这并不是万无一失的——但如果你在不合标准的硬件上运行，升级仍然便宜得多。

接下来，在服务器上运行 SQL Server Profiler。尝试过滤掉噪音 - 这是一个相当嘈杂的工具 - 并在多个用户使用该应用程序时寻找长时间运行的查询。通常，您只会看到导致大多数性能问题的少数查询（但并非总是如此）。创建一个运行缓慢的列表（我使用 1 秒作为截止点）。

在开发环境中获得运行缓慢的查询列表后，请对其进行优化。查看查询计划以确保它们使用正确的索引，并查看它们的编写方式。如果您仍然卡住，请返回并发布特定查询和示例数据以供我们查看。

【讨论】：