在写这篇东西的时候我也不是很清楚性能基线，到底要检查点什么，dmv要不要检查，perfmon要检测那先。
所以我决定，对我发的《sql server 性能调优》文章内的 perfmon和dmv做一个总结。来建立自己的性能基线。

io

在io中我们要注意哪些性能指标呢？
1. physical disk\disk reads/sec --这个应该很清楚 一看就就知道 这个指标是指什么的
2. physical disk\ disk writes/sec
一打开文章就看到这2个值，而却有阀值，看到阀值很开心，因为不用你去收集值了。
Less than 10 ms = good performance
Between 10 ms and 20 ms = slow performance
Between 20 ms and 50 ms = poor performance
Greater than 50 ms = significant performance problem.
接下来就是 sys.dm_os_wait_stats 中的几个wait type
3. PAGEIOLATCH_*
PAGEIOLATCH_* 系列的wait type 一共有
PAGEIOLATCH_DT -- 破坏，什么是破坏，就是把内存中数据页释放掉
PAGEIOLATCH_EX -- x锁，可以怎么理解，就是排他占用这个锁
PAGEIOLATCH_KP -- 保持，就是保持这个页不被破坏
PAGEIOLATCH_NL -- 没有定义，保留
PAGEIOLATCH_SH -- 在读，数据页的时候就分配这个闩
PAGEIOLATCH_UP -- 在更新的时候分配这个
根据onlinebook的解释：在任务等待 I/O 请求中缓冲区的闩锁时发生。闩锁请求处于“XX”模式。长时间的等待可能指示磁盘子系统出现问题。
讲的直白一点就是系统在io，入读或写的时候分配的。等待io请求
4. ASYNC_IO_COMPLETION
根据onlinebook的解释：当某任务正在等待 I/O 完成时出现
这个是等待异步io完成，那么和上面有没有关系呢？答案是没有，上面等待的是io读取出来，或者写入。这个是等待系统的异步io完成是不一样的概念。
5. IO_COMPLETION
根据onlinebook的解释：在等待 I/O 操作完成时出现。通常，该等待类型表示非数据页 I/O。数据页 I/O 完成等待显示为 PAGEIOLATCH_* waits。
这个就不解释了说的很明白了就是等待非数据页的io完成
6. WRITELOG
根据onlinebook的解释：等待日志刷新完成时出现。导致日志刷新的常见操作是检查点和事务提交。
这个也不多解释，就是写入日志时候等待的时间。

cpu

7.Processor/ %Privileged Time --内核级别的cpu使用率
8.Processor/ %User Time --用户几倍的cpu使用率
9.Process (sqlservr.exe)/ %Processor Time --某个进程的cpu使用率
10.SQLServer:SQL Statistics/Auto-Param Attempts/sec --试图运行自动参数化次数
11. SQLServer:SQL Statistics/Failed Auto-params/sec -- 自动参数化失败
12. SQLServer:SQL Statistics/Batch Requests/sec -- 批处理量
13. SQLServer:SQL Statistics/SQL Compilations/sec -- 编译次数
14. SQLServer:SQL Statistics/SQL Re-Compilations/sec -- 反编译次数
15. SQLServer:Plan Cache/Cache hit Ratio -- 执行计划，cache命中率
接下来还是 wait event的
16.signal_wait_time_ms --从发出信号到开始运行的时间差，时间花费在等待运行队列中，是单纯的cpu等待。
下面代码量化的像是signal_wait_time_ms占的比重
SELECT SUM(signal_wait_time_ms) AS TotalSignalWaitTime ,
( SUM(CAST(signal_wait_time_ms AS NUMERIC(20, 2)))
/ SUM(CAST(wait_time_ms AS NUMERIC(20, 2))) * 100 )
AS PercentageSignalWaitsOfTotalTime
FROM sys.dm_os_wait_stats
在创建baseline 的时候 完全可以 按这个sql来获取值。
17.SOS_SCHEDULER_YIELD等待
onlinebook的解释:在任务自愿为要执行的其他任务生成计划程序时出现。在该等待期间任务正在等待其量程更新。
完全看不懂，啥叫量程。
直白的说就是：当查询自动放弃cpu，并且等待恢复执行，这个等待就叫做SOS_SCHEDULER_YIELD。
18.CXPACKET等待
onlinebook:当尝试同步查询处理器交换迭代器时出现。如果针对该等待类型的争用成为问题时，可以考虑降低并行度。
直白点就是：处理器之间的一种同步，一般出现在 并发查询，为啥？因为只有并发查询才用多个处理器。
接下来是 sys.dm_os_schedulers
SELECT scheduler_id ,
current_tasks_count ,
runnable_tasks_count
FROM sys.dm_os_schedulers
WHERE scheduler_id < 255
19.主要是查每个处理器上的任务数和可运行的任务数。

内存