网上看到这篇文章挺不错的，直接翻译过来。
在尝试诊断SQL Server性能时，不要仅仅依赖某个单一的诊断数据，比如CPU的使用率、SQL Server磁盘性能，就得出结论却忽略的问题的根源。实际上，使用单一的度量经常会得出一个错误的诊断。
在SQL Server中CPU、IO和内存的使用是相互依赖。在我们采取"knee-jerk"修正行动(添加内存、提升磁盘吞吐量或者更改配置设置)之前，我们需要先查看整体情况。
一、服务器级别
"进程X运行缓慢，你能修复它吗？"
作为DBA，你决定打开资源监视器(resmon)，发现磁盘活动异常
在性能监视器(perfmon)查看部分磁盘相关的计数器
伴随着磁盘请求队列的平均长度急剧上升，从磁盘读取数据存在较高的延迟。好像磁盘子系统成为一个瓶颈，它正努力跟上请求数量，SQL Server磁盘IO性能恶化，队列形成。
你应该采取什么行动解决这个问题呢？在你打算联系系统管理员去看是否可以做些什么来提升磁盘能力，你最好是再深入挖掘下。
如果你只关注一个特定的性能指标，很容易对SQL Server性能问题进行误诊。
你可能有证据表明存在一个特定的瓶颈，但是在本例SQL Server磁盘IO，把磁盘性能不够或者磁盘子系统配置当成问题的根源就有点危险了。
The excessive disk IO could easily have its root cause elsewhere.你需要收集更多的数据来确认问题的根源。但是，你从哪里开始呢？
二、深入挖掘
2.1、Wait statistics
一个好的开始是分析SQL Server等待统计，它通常能够表明为什么SQL Server会话在获取所需资源以执行请求前被迫暂停处理(等待)。通过分析等待，我们可以识别繁忙的服务器上主要引起争用的资源。
查询sys.dm_os_waiting_tasks动态管理视图(DMV)，显示所有正在等待资源执行的语句，可以关联其他DMVs得到相关会话和请求的详细信息。作为演示，我们执行以下脚本
--Analyze the queries that are currently running or which have recently ran and their plan is still in the cache. SELECT dm_ws.wait_duration_ms, dm_ws.wait_type, dm_es.status, dm_t.TEXT, dm_qp.query_plan, dm_ws.session_ID, dm_es.cpu_time, dm_es.memory_usage, dm_es.logical_reads, dm_es.total_elapsed_time, dm_es.program_name, DB_NAME(dm_r.database_id) DatabaseName, -- Optional columns dm_ws.blocking_session_id, dm_r.wait_resource, dm_es.login_name, dm_r.command, dm_r.last_wait_type FROM sys.dm_os_waiting_tasks dm_ws INNER JOIN sys.dm_exec_requests dm_r ON dm_ws.session_id = dm_r.session_id INNER JOIN sys.dm_exec_sessions dm_es ON dm_es.session_id = dm_r.session_id CROSS APPLY sys.dm_exec_sql_text (dm_r.sql_handle) dm_t CROSS APPLY sys.dm_exec_query_plan (dm_r.plan_handle) dm_qp WHERE dm_es.is_user_process = 1 GO --You can change CROSS APPLY to OUTER APPLY if you want to see all the details which are omitted because of the plan cache