SqlServer性能监控和优化总结

如何监视和查看sql server的性能

http://jingyan.baidu.com/article/a378c9609af34eb32828303a.html


打开sql server studio management


打开"工具"-"sql server profiler"


点击连接


点击运行


可以看到捕捉到的一些访问数据库的事件，其中有读写，点用cpu，持续时间等信息可以参考


点击某个事件，可以查看具体执行了什么sql脚本，进一步分析相关逻辑。
========

利用sql server监控数据库访问

http://jingyan.baidu.com/article/f3e34a12a92bc3f5eb6535ba.html


本例分享使用sql server中的profiler监控数据库的操作情况。


1
打开sql server profiler；
2
新建跟踪；
3
连接数据库服务器并运行跟踪程序；
4
只要保持程序是运行状态，就可以即时的监测到数据库的操作情况了。如图所示，是本例示范时数据库


的访问状况。
========

sql server 在占用服务器内存居高不下怎么办

简介：本人在开发sql server数据库项目的过程中发现了这么一个问题，通过360安全卫士的浮动显示图


标表示 sql server 2005 居然像oracle一样占用了80%的系统资源，消耗资源居高不下，怎么回事啊？


问了一起工作的同事，他们给出了下面的几个建议：


1、做个软件自动给sql server 2005数据库强制释放内存；
注：这个是可以的，但是这样做很不合理；一方面服务器上的web系统正在运行，如果此时我们把系统的


内存释放掉了这样肯定会引起网页OA系统的异常。
2、给sql server 2005 做个任务来释放内存；这个好像是可以的！但是这个也是很麻烦的事情。
很明显上面的方法都不是最理想的。


下面就是正确处理由于sql server 2005引起的数据库内存居高不下的办法：
首先我们需要登录 sql server 2005的资源管理器
鼠标右击我们sql server 2005的服务器，然后选择“属性”选项
找到指定数据库服务器的属性中的“内存”属性，并点击
接下来就是配置数据库内存了，可以参考我本地的配置如下图：
最后点击“确定”按钮就可以了！
========

怎么设置sql2008数据库最大服务器内存

http://jingyan.baidu.com/article/ceb9fb10b415bb8cac2ba078.html


通过设置SQL Server 2008 R2服务器中的最大服务器内存，可以解决使用数据库时占用系统内存过高的


问题。那么我们该怎么操作呢


1.选择“开始 > 所有程序 > Microsoft SQL Server 2008 R2 > SQL Server Management Studio”。系


统显示“连接到服务器”界面。
2.输入各项数据，单击连接
3.系统显示“对象资源管理器”界面
4.上图单击右键，在弹出的快捷菜单中选择“属性”。
5.在左侧导航栏中选择“内存”，将右侧“最大服务器内存”的值设置为物理内存的60%，本例以8G内存


为例
6.最后单击确定，设置完成
怎么设置sql2008数据库最大服务器内存
END
========

对SQLSERVER进行性能监控

http://www.cnblogs.com/lyhabc/archive/2013/07/13/3187581.html


在上一篇文章《SQLSERVER性能监控级别步骤》里说到性能监控的步骤中有一步涉及到建立性能基线，但


是没有说到有哪些计数器
可以用来进行监控的，这篇文章结合《企业级平台管理实践》的书本说一下监控SQLSERVER有哪些计数器


可以用到的


3、建立性能基线
 当确定了性能监控中所涉及的资源、负载和目标后，开始进行监控，并建立性能基线与当前服务器性能


进行比较。
性能基线是一个保证系统正常操作性能范围值，达到或超过这个范围，系统性能可能会显著下降。
应该对接近或超过性能基线的数字做进一步调查找出原因监控的周期是一段时间，而不是一两天。
其中应该包括数据库活动的峰值时间和非峰值时间，数据查询和批处理命令的响应时间、数据库备份和


还原所需时间
建立服务器性能基线后，将基线统计与当前服务器性能进行比较。对高于或远低于基线的数字需要做进


一步调查。
他们可能表明有需要调整或重新配置的区域。例如，执行一组查询的时间增加，检查这些查询以确定能


否重新编写他们，
或者是否添加统计信息或索引


介绍：


性能监视器 Performance Monitor


性能监视器是Windows的一个工具，在系统管理工具组里。默认里面就有很多Windows层面的性能计数器


，可以监视系统的运行。


直接运行"perfmon"，也可以打开他。这里以 WindowsXP/2003/2008的性能监视器为例。


Windows2008R2和Windows7的性能监视器界面有了比较大的变化，功能也有扩展，更加好用。同时也完全


向前兼容。


后面谈到的功能都有包括


SQLSERVER自己开发了一些扩展的性能计数器。在安装SQLSERVER的时候，会注册到Windows里。


这样， Windows的性能监视器就能看到一些以“SQL”打头的计数器了。SQLSERVER在运行时，会统计这


些计数器的值。


在性能监视器里能够看到：


默认性能监视器是用来实时检测系统的，在窗口里，用不同颜色的线条表示不同的计数器值。


当窗口画满以后，会从头覆盖前面的内容。所以默认只能看到最近一小段时间的值。


但是在现实的问题分析中，实时监测还是比较少的。更常见的场景是需要在问题发生之前，就要开启性


能计数器的收集，


收集一段时间之后，或者问题重现之后，再离线地分析问题的现象和原因。


那么日志怎样收集呢？


通常可以使用下面这些步骤：


（1）在性能监视器左边的窗口，展开性能 日志和警告子树，点击“计数器日志” 在右边的窗口里，右


键点击，


选择“新 日志设置”，他会弹出一个对话框，让你为新的日志记录配置命名。这里我们取名为Test，日


志默认保存路径是


%systemdrive%\PerfLogs\Admin\Test


（2）在接着弹出的对话框里，就可以配置DBA要搜集的信息要求了。首先要选择搜集哪些计数器，以及


他们的取样时间间隔sample data every，


默认是15秒取一次，这个间隔能够满足大部分需求。


有说法讲在搜集和磁盘相关的性能日志时，间隔要设置短一点，最好是3到5秒。如果设置30秒以上，可


能信息就不完整了。


所以15秒是大部分情况下比较好的选择


（3）选择添加对象，就可以选择要收集的性能监视器对象。对于非在线分析，问题可能还不清楚，很难


确定哪些性能计数器有用，哪些没有用。


所以在这里，一定要多选一些。一般的SQL问题，可以选择下面这些对象


在memory,process,physicaldisk,processor,system对象下的所有计数器，以及他们的所有instance


所有以SQLSERVER：开头的性能监视对象


如果要监视CPU类问题，最好还包含thread下面的所有计数器，以及他所有的instance


有些DBA会担心，抓这麽多计数器会不会影响性能。


应该说根据经验，性能监视器对系统整体性能的影响几乎感觉不到。所以可以比较放心大胆地多收一些


计数器。


基本工作原理是在.NET编译出的IL代码里放入钩子用来记录时间，然后通过直观的界面显示出哪部分代


码耗能最大。


只是间隔可能还是选15秒比较安全


（4）设置文件的位置和最大大小 ，另一个重要配置，是日志文件存放在哪里，保存格式，以及最大大


小。


日志文件的后缀是blg的二进制文件，需要使用性能监视器才能打开这个文件


如果性能日志文件大小超过1GB，可能有些机器打开会很慢。所以一定要注意其最大值可以设为200MB。


如果一个200MB的文件写满，性能监视器会自动创建一个新的。文件格式可以选二进制文件


日志搜集当然可以手动开始和终止。但是如果问题会发生在半夜，最好能让系统自动开启，自动关闭。


性能监视器也可以帮DBA做到这一点


当得到一个性能日志后，可以在性能监视器里选择 查看 日志 数据


在数据源里添加日志文件


然后点击数据选项卡，就能看到在原来那台服务器上收集的性能计数器了


这时候再点击“源”选项卡，能看见性能日志文件所包含的那段时间。拉动滚动条，可以把时间段缩短


到DBA最关心的那段时间


对收集到的日志，DBA可以进行分析


------------------------------华丽的分割线---------------------------
一些性能监视器计数器
相关计数器


性能对象                                                 计数器
SQLSERVER:BUFFER MANAGER:    buffer cache hit ratio,lazy writes/sec ,procedure cache 


pages,total pages
SQLSERVER：Cache Manager:    cache hit ratio,cache object counts,cache pages ,cache use 


counts/sec
SQLSERVER:MEMORY MANAGER:    sql cache memory(kb)
SQLSERVER:SQL STATISTICS:    auto-param attmpts/sec,batch request/sec,failed auto-


params/sec,safe autoparam/sec, sql compilations/sec,


sql re-compilations/sec,unsafe auto-params/sec


----------------------------华丽的分割线--------------------------
与内存有关的计数器


Windows与SQLSERVER系统使用内存情况和合理配置SQLSERVER内存 


性能监视器  perfmon --添加-》可用计数器-》Memory-》添加available MBytes和pages/sec


数据收集器集-》用户定义-》新建-》数据收集器集-》名称：SQLSERVER内存使用-》手动创建-》性能计


数器-》 添加下面的性能计数器-》


时间间隔15秒-》保存路径：C:\Users\Administrator\Desktop\SQLSERVER内存使用-》 保存并关闭-》


选中刚才创建的数据收集器-》启动-》变成


datacollector01   -》在用户定义下面 SQLSERVER内存使用 右键-》停止或者在空白的地方-》右键-》


停止


可以右键-》在用户定义下面 SQLSERVER内存使用-》属性-》更改数据收集器保存路径


 计数器


committed bytes:整个Windows系统，包括Windows自身以及所有用户进程使用的内存总数


commit limit:整个Windows系统能够申请的最大内存数，其值等于物理内存加上文件缓存大小


available MBytes（重要）:现在系统空闲的物理内存数。这个指标能够直接反映出Windows层面上有没


有内存压力跑在Windows2000上会把空闲内存用完知道剩下4MB~10MB。跑在Windows2003或以上就会留给


Windows多一点的物理内存


page file :%usage  page file:% peak usage ：反应缓存文件使用量的多少，使用越多缓存，性能越


差


pages /sec:每秒钟需要从磁盘上读取或写入的页面数目


soft page fault一般不会带来性能影响，因此一般不太关心


一个良好的系统，他要处理的数据应该比较长期地保存在物理内存里。如果频繁换页/换入换出势必影响


性能，pages/sec不能长时间保持在一个比较高的值


对于一台SQL服务器，如果available MBytes长期小于10MB，说明物理内存不太够pages/sec 物理内存不


足也会做成频繁换页/换入换出 pages/sec不能长时间保持在一个比较高的值


Windows系统自身内存使用情况


一个32位Windows系统，正常内存使用大概几百MB --64位Windows系统大概1GB~2GB


--如果发生内存泄漏（一般由硬件驱动造成），Windows会用到几个GB甚至十几GB，反过来挤压应用的内


存


memory :cache bytes --系统的working set，也就是系统使用的物理内存数目，包括高速缓存，页交换


区，可调页的ntoskrnl.exe 和驱动程序代码，


以及系统映射视图


cache bytes计数器是下面几个计数器的和：


system cache resident bytes,system driver resident bytes ,system code resident bytes ,pool 


paged resident bytes


system cache resident bytes:系统高速缓存消耗的物理内存。高速缓存的主要功能是提高文件读写的


速度


pool paged resident bytes：页交互区消耗的物理内存


system driver resident bytes：可调页的设备驱动程序代码消耗的物理内存


system code resident bytes：ntoskrnl.exe中可调页代码消耗的内存


system pool 内存池  如果两个重要的内存池内存出现泄漏，或者空间用尽，Windows会出现奇怪不正常


的行为， 进而影响SQL稳定运行。


所以需要检查这两个内存池


pool nonpaged bytes 非换页内存池


pool paged resident bytes 换页内存池


单个process使用情况


常见场景：available MBytes看出服务器的内存基本用尽，但是从cache bytes看Windows自己没有使用


多少。


现在要开始分析应用程序的内存使用了


在选择对象的实例里面要每个进程都要添加进计数器里面，不要选择_Total SQL的进程是sqlservr


%processor time:是目标进程消耗的CPU资源数，包括用户态和核心态的时间


page faults/sec:是目标进程上发生的page faults的数目


handle count：目标进程handle(指向object指针)数目句柄数。如果进程内部有对象老是创建，不及时


回收，就会发生handle leak


thread count:目标进程的线程数目。如果进程老是创建新线程，不释放老线程，就会发生thread leak


pool paged bytes:是目标进程所使用的paged pool大小


pool nonpaged bytes:是目标进程所使用的non-paged pool大小


working set:某个进程的地址空间，存放在物理内存的那一部分


virtual bytes:某个进程所申请的虚拟地址空间大小，包括reserved memory 和committed memory


private bytes:某个进程提交了的地址空间commited memory中，非共享部分


假设有processA 和processB,他们的虚拟地址空间都分成两部分，核心态和用户态 --核心态是由


Windows控制，所有进程共享。


processA --committed memory :1,2,3,4,7 --reserved memory:8 --shared memory:通过特殊API申请


的内存，processA和processB都能够访问


物理内存physical memory：1，3，4，d，7，9，b，c 缓存文件page file：2，y


系统核心态内存 system working set=x


检查计数器主要找到以下：


使用内存最多的进程


内存使用量在不断增长的进程


出现问题的那个时间段，内存使用数量发生过突变（增或降）的进程


这些可以通过working set  private bytes得到初步答案


 -----------------------------华丽的分割线--------------------


上面这些都是《SQLSERVER企业级平台管理实践》读书笔记整理出来的一些常用SQLSERVER性能计数器，


大家做性能基线的时候都可以用来做参考
========

SqlServer性能检测和优化工具使用详细

http://blog.csdn.net/dcx903170332/article/details/45917387


工具概要    
    如果你的数据库应用系统中，存在有大量表，视图，索引，触发器，函数，存储过程，sql语句等等


，又性能低下，而苦逼的你又要对其优化，那么你该怎么办？哥教你，首先你要知道问题出在哪里？如


果想知道问题出在哪里，并且找到他，咱们可以借助本文中要讲述的性能检测工具--sql server 


profiler（处在sql安装文件--性能工具--sql server profiler）


    如果知道啦问题出现在哪里，如果你又是绝世高手，当然可以直中要害，写段代码给处理解决掉，


但是如果你不行，你做不到，那么也无所谓，可以借助哥的力量给你解决问题。哥给你的武功的秘诀心


法是---数据库引擎优化顾问（处在sql安装文件--性能工具--数据库引擎优化顾问）


sql server profiler功能 
    此工具比柯南还柯南，因为他能检测到数据库中的一举一动，即便你不动他，他也在监视你，他很


贱的。他不但监视，还监视的很详细，有多详细一会再说，还把监视的内容记录到数据库或者是文件中


，给你媳妇告状说你把数据库哪里的性能搞的多么不好，不过他也会把好的给你记录下来，好与不好这


当然需要你来分析，其实他也是个很2的柯南。


数据库引擎优化顾问功能 
    此武功，乃上乘武功。像张无忌的乾坤大挪移，先是接受sql server profiler检测出来的sql，视


图，存储过程，数据结构等等，然后他再自己分析，然后再在怀中转两圈，感觉自己转的差不多啦，就


给抛出来个威力更炫，更好的索引，统计，分区等等建议信息。让你承受不住，happly致死。。下面听


哥给你先讲讲咱们的很2柯南。


sql server profiler的使用
打开系统主菜单--sqlserver几---性能工具--->>sql server profiler;笨样儿，找到没？哥等你会儿，


给你上张打开他后的图，让你看看。。


然后文件--新建跟踪--显示跟踪属性窗口


然后选中页签“事件选择”，并点击”列筛选器“，操作如下图：


首先那个select%是个筛选监测的TextData。那个%是个通配符，他的意思就是筛选select开口的语句。


当然这你自己可以随便定义，如update%，delete%....。


把那个排除不包含值的行也给带上，然后确定，运行。然后在数据库中运行一句select。你会发现他检


测到啦。


每列以此向右，从EventClass开始，我给你讲讲都是什么。


事件分类，申请了语句，应用程序名称，操作系统用户，数据库用户，cpu占用率，读数据库次数，写数


据库次说，执行脚本用时，应用程序进程号，开始时间，结束时间等。


事件选择，你就把鼠标放上去，他下面有中文的注释。自己好好看看，然后根据你自己的需要把事件勾


选上来。


然后文件-->>另存为，可以把这些监测到的数据保存为文件，或数据表。


分析：


1.查找持续时间最长的查询


一般情况下，最长查询时间的查询语句就是最影响性能的原因存在。它不仅占用数据库引擎大量的时间


，还浪费系统资源，还影响数据库应用系统的交互速度。再对数据用应用系统进行优化时，先找出他，


对其优化，在创建跟踪时，勾上TSQL-SQL:BatchCompleted.跟Stored Procedures-RPC:completed。这样


就能找出来这个最长时间查询然后对其进行分析优化。


select TextData,Duration,CPU from <跟踪的表>
where EventClass=12 -- 等于12表示BatchCompleted事件
and CPU<(0.4*Duration)  --如果cpu的占用时间，小于执行sql语句时间的40%，说明该语句等待时间过


长
2.最占用系统资源的查询


就是占用cpu时间，跟读写IO的次数。建议事件包含Connect、Disconnect、ExistingConnection、


SQL:BatchCompleted、RPC:completed，列包含writes，reads，cpu。


3.检测死锁


在访问量，并发量都很大的数据库中，如果设计稍不合理，就有可能造成死锁，给系统性能带来影响。


事件包含：RPC:Starting、SQL:BatchStarting、Lock：DeadLock（死锁事件）、Lock：


DeadLockChaining（死锁的事件序列）。


使用数据库引擎优化顾问分析解决数据库性能
打开系统主菜单--sqlserver几---性能工具--->>数据库引擎优化顾问，界面如下


打开之后，你在上一个工具中保存的的文件，你就在这里的工作负荷中选文件，表就选表。选后别急。


把要分析的数据库跟数据库的表选上，也就是下面的用于工作负荷分析的数据库选择，跟下面的要优化


的数据库和表，慢慢扣，把他选对。


然后选则你想要的优化选项


根据需要，选上，高级选项里面通常可以默认。确定。。


然后点左上角有一个开始分析。如果报下面的错误，不要急，按照他的操作一步一步来就行。


点击tab标签"优化选项",如图：


然后点击“高级选项”：、


点击确定----开始分析-----一会就分析完成了


 它会给个建议列表，然后你根据上面的操作，把它给出的操作在数据库中操作下就OK了，就不用那么的


费尽心机的调试SQL了，当然写出高效率的SQL还是比较好的。
========

sql server性能分析--查看表数据页数

返回表名、索引名和行数
SELECT object_name(i.object_id) as objectName, i.[name] as indexName, sum(p.rows) as rowCnt
FROM sys.indexes i
INNER JOIN sys.partitions p
ON i.object_id = p.object_id
AND i.index_id = p.index_id
WHERE i.object_id = object_id('dbo.Meeting')
AND i.index_id <= 1
GROUP BY i.object_id, i.index_id, i.[name]


返回表的总页数、使用页数、数据页数
SELECT object_name(i.object_id) as objectName, i.[name] as indexName,
sum(a.total_pages) as totalPages, sum(a.used_pages) as usedPages, sum(a.data_pages) as 


dataPages,
(sum(a.total_pages) * 8) / 1024 as totalSpaceMB, (sum(a.used_pages) * 8) / 1024 as 


usedSpaceMB,
(sum(a.data_pages) * 8) / 1024 as dataSpaceMB
FROM sys.indexes i
INNER JOIN sys.partitions p
ON i.object_id = p.object_id
AND i.index_id = p.index_id
INNER JOIN sys.allocation_units a
ON p.partition_id = a.container_id
WHERE i.object_id = object_id('dbo.Meeting')
AND i.index_id <= 1
GROUP BY i.object_id, i.index_id, i.[name]


按页类型分类统计
SELECT case when grouping(i.object_id) = 1 then '--- TOTAL ---' else object_name


(i.object_id) end as objectName,
case when grouping(i.[name]) = 1 then '--- TOTAL ---' else i.[name] end as indexName,
case when grouping(a.type_desc) = 1 then '--- TOTAL ---' else a.type_desc end as pageType,
sum(a.total_pages) as totalPages, sum(a.used_pages) as usedPages, sum(a.data_pages) as 


dataPages,
(sum(a.total_pages) * 8) / 1024 as totalSpaceMB, (sum(a.used_pages) * 8) / 1024 as 


usedSpaceMB, (sum(a.data_pages) * 8) / 1024 as dataSpaceMB
FROM sys.indexes i
INNER JOIN sys.partitions p
ON i.object_id = p.object_id
AND i.index_id = p.index_id
INNER JOIN sys.allocation_units a
ON p.partition_id = a.container_id
WHERE i.object_id = object_id('dbo.Meeting')
AND i.index_id <= 1
GROUP BY i.object_id, i.[name], a.type_desc with rollup
========

SQL Server性能之瓶颈的正确查看步骤

http://database.51cto.com/art/201007/210767.htm


我们今天主要向大家讲述的是正确查出SQL Server性能之瓶颈的实际操作流程，以及对SQL Server数据


库性能监控的实际操作描述。
AD：网+线下沙龙 | 移动APP模式创新：给你一个做APP的理由>>
以下的文章主要向大家介绍的是正确查出SQL Server性能之瓶颈的实际操作流程，假如你对DBA很了解的


话，那么你就一定会了解到SQLServe数据库的性能调优不是一个精密的科学。即使是，对于为最佳的SQL 


Server性能找到最佳的配置也是很困难的。


这是因为对于调优来说很少东西是绝对的。例如，一个性能调优可能对某一方面有


如果你曾经做了很长时间的DBA，那么你会了解到SQLServe的性能调优不是一个精密的科学。即使是，对


于为最佳的性能找到最佳的配置也是很困难的。这是因为对于调优来说很少东西是绝对的。例如，一个


性能调优可能对某一方面有用，可是却会影响其他的性能。


我曾经做过DBA，在最后7年的日子里，我总结了一套SQL Server调优的清单。当第一次进行SQL Server


性能调优的时候，可以用它来作为一个向导。我经常被邀请去检查SQL Server并提供一些性能方面的建


议。直到现在，我还没有真正写下一个贯穿整个性能调优过程的方案。


但是当我做了越来越多的性能调优的咨询工作后，我现在决定花点时间整理出来。你将会发现它是很有


用的，就象我发现对我的用处一样.


SQL Server性能监控


这套性能优化的清单将至少准科学的帮助你找出你的SQL Server任何明显的性能问题。说是这样说，SQL 


Server的性能调优仍然是很困难的。我试图用这套清单去找出“容易”的SQL Server性能问题，困难的


留待稍后。我这样做是因为很容易将容易和困难的的性能调优问题搞混。通过列出一个“容易”的性能


调优范围，就很容易的将这些问题解决，一旦解决了这些容易的问题，那么你就能集中去解决更困难的


问题。


使用这个SQL Server性能调优清单的一个好处是，它将不仅仅告诉你目前最容易解决的性能问题是什么


，而且还帮助你正确的去解决。在某种程度上，你可以选择不同的顺序进行。换句话说，你可以故意做


出特殊的决定而不是按照清单通常的顺序进行。


某种意义上说你是对的，不是所有的SQL Server性能调优建议都适合所有的情形。另外，你的决定是基


于你的资源限制，例如没有足够的钱去买满足负荷的硬件。如果真是那样的话，你就别无选择了。还有


，你的决定可能基于一些政治原因，那是你不得不作出的改变。不管怎样，你需要知道你能做什么，使


用这个性能调优清单找出你能改变的范围并做出相应的改变提升你的SQL Server的性能。


一般来说，你将在你的每一个SQL服务器上执行这个清单。如果遇到清单中的一些问题，这会花掉你一些


时间。我建议你从目前性能问题最多的的服务器开始，然后当你有时间的时候按照自己的思路去解决其


他服务器。


一旦你完成了，可仍然有很多事情要去做。记住，这些只是一些容易的。一旦你完成了这些容易的，接


下来你需要花时间去解决更困难问题。这个是另一篇文章要解决的问题了。


怎样进行你的SQL Server性能调优呢?


为了使其变得容易，我把它们分成了以下几个部分：


使用性能监视器找出硬件瓶颈


SQL Server硬件性能监控列表


操作系统性能监控列表


SQL Server2000配置性能监控列表


数据库配置设置性能监控列表


索引性能监控列表


应用程序和T-SQL性能监控列表


SQL Server数据库作业性能监控列表


使用Profiler找出低效的查询


怎样最好的实现SQL Server性能监控


管理你的SQLServe性能的最好方法是首先回顾上面每一部分的内容，把它们打印出来。然后完成每一部


分的内容，写下你收集到的结果。你也可以按照你喜欢的顺序进行。上面的步骤仅仅列出了我执行的顺


序，因为那样通常能达到一个比较好的效果。


一旦你完成其中一部分，你可以按照在清单中发现的不同的建议进行你的性能优化工作。然后你将在后


面的部分学到更多。


以上的相关内容就是对查出SQL Server性能之瓶颈的介绍，望你能有所收获。
========

链接

http://blog.csdn.net/kufeiyun/article/details/23743647
SQL Server查询性能调优、捕捉和评估查询性能


http://www.360doc.com/content/14/0415/14/3112151_369179018.shtml
怎样查出SQLServer的性能瓶颈