查询优化

查询优化处理步骤

1  分析实例等待

2 联系等待和队列

3 确定方案

4  细化到数据库/文件级

5 细化到进程级

6 优化索引/查询

 

1 分析实例等待

 处理性能问题时候，一般考虑资源队列。资源利用率

用DMV找出那些等待类型占用了大部分等待时间。

运行下面语句返回你系统中所有的等待

SELECT
  wait_type,
  waiting_tasks_count,
  wait_time_ms,
  max_wait_time_ms,
  signal_wait_time_ms
FROM sys.dm_os_wait_stats
ORDER BY wait_type;

DMV 重服务器最后一次重新启动开始累积值。如果你想重置他的值，运行下面的代码；

DBCC SQLPERF('sys.dm_os_wait_stats',CLEAR);4

处理经验

I/O等待是到目前为止客户是遇到最常见的等待。其中有几个原因

I/O通常是数据处理操作所涉及的最昂贵的资源。当对查询或索引的设计或优化不理想时，通常会造成额外的I/O.通常我们在考虑计算机性能时，通常只关注CPU和内存，而不会给I/O子系统给予足够的的关注。

另外一种情况频繁的访问少量数据，这中情况代码的编译和重新编译可能会成为瓶颈的主要原因。联机事物处理系统还涉及大量对少量数据的数据修改，在这中环境下事物日志经常会成为一个瓶颈。因为所有临时的表都在数据库中创建，tempdb数据库也可能成为一个非常严重的瓶颈。

下面的查询可以找出累计值达到系统等待时间超越百分之90的等待

WITH Waits AS
(
  SELECT
    wait_type,
    wait_time_ms / 1000. AS wait_time_s,
    100. * wait_time_ms / SUM(wait_time_ms) OVER() AS pct,
    ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS rn
  FROM sys.dm_os_wait_stats
  WHERE wait_type NOT LIKE '%SLEEP%'
  -- filter out additional irrelevant waits
)
SELECT
  W1.wait_type,
  CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s,
  CAST(W1.pct AS DECIMAL(12, 2)) AS pct,
  CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct
FROM Waits AS W1
  JOIN Waits AS W2
    ON W2.rn <= W1.rn
GROUP BY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct
HAVING SUM(W2.pct) - W1.pct < 90 -- percentage threshold
ORDER BY W1.rn;
你可以调整这个临界值并过滤调其他一些不相关的等待。如果你希望输出中至少包含N行 假设n = 10； 在HAVING子句中增加表达式or W1.rm <= 10。对于每种等待类型，该查询都会返回 重系统最后一次重启以来该等待类型的累积等待时间，