如果您收到关于SQL Server性能问题的调用/页面，您首先要做什么？
开始一个跟踪？ popupPerfmon？ 打开活动监视器？
这些都是有用的工具，但是你的“sorting”是什么？
依靠。
这是一个突如其来的突破性performance，是一个死缓的问题，还是一个普遍performance不佳的长期案例？
如果是前者，我将从与执行相关的DMV（sys.dm_exec_requests）开始。 有没有阻塞？ 是否有查询运行时间过长或使用大量资源？ 基本上我会寻找一些不正常的东西（注意，为了能够看到，我必须知道什么是正常的）
如果是后者，我将使用我在这些文章中所写的方法。
第一件事？ 与用户交谈。
什么改变了？
这是不好的performance一个新的东西，它突然出现或刚刚build立？
您的历史报告在过去一个月中显示了什么（SQLH2）？
检查服务器的磁盘空间，内存使用情况，CPU使用情况（该顺序）。 服务器安装是否正确（ram设置） – taskmgr。
检查性能自己。 这对你来说似乎很慢吗？
用户是否习惯于从新系统（无数据）“即时”执行，现在开始拖动？
那么你可以开始调查可能的问题。 你必须先build立一个基准，否则你永远不会知道什么时候完成。
在我做所有上述build议之前，我会这样做：
SELECT @@total_read AS 'Total Read', @@total_write AS 'Total Write', @@total_errors AS 'Total Error', @@io_busy AS 'IO Processing Time (ms)', @@cpu_busy AS 'CPU Processing Time (ms)', @@idle AS 'Idle Time (ms)' [我正在参考我的博客文章： http : //dbalink.wordpress.com/2009/04/28/monitoring-sql-server-performance-quickie-edition/ ]
使用SQLIO 。 你可以阅读一大堆关于使用哪个开关/咒语的东西，但是只要在MDF / LDF存储的驱动器（例如sqlio.exe / dCDE）上运行，就会给你一个很棒的标题“MBs / sec”进行比较。 我跟踪了我们的应用程序在客户端的性能不佳，直到日立AMS（光纤通道磁盘系统）上的磁盘/ LUN争用。 我的笔记本电脑磁盘执行10倍更好！ 不久，我们的数据库拥有自己的LUN，我们的应用程序又开心了。
检查日志文件，特别是可能有的任何“长查询”日志logging。 如果没有打开，请打开它。
检查一般机器的健康状况 – 它可能不是SQL服务器，它可能是整个机器 – 检查失控进程，整体CPU使用率，整体内存使用情况 – 你用cacti或类似的东西来绘制这些东西进行历史比较，对吧？ 所以检查图表，看看什么时候开始缓慢。
要添加到列表中：
查看错误日志：
检查索引碎片。 检查您是否设置了适当的自动增长，并启用即时初始化。 检查您没有启用自动缩小。
关于所有这些在我的博客上的信息 – 可以发布链接，如果你想。
隔离问题
sp_lock或sys.dm_tran_locks ） 隔离到存储过程或视图
@tables应该是@tables seeks scans的执行计划 SET STATISTICS IO ON等）以获得基准性能数字 这取决于这个问题，但通常我做的第一件事就是看代码，看它是否是效率低下的原因。 我通常然后检查受影响的表格，并确保它们具有所有适当的索引等。