我有一张表，共有56个字段。发现以下情况：
1、我在我的开发机执行sql语句
set statistics time on
SELECT * FROM [eShop].[dbo].[Product]（多次执行，时间平均在90-100ms）
2、在服务器上有相同的数据库，相同的表，相同的内容。执行同样SQL语句，执行结果为：（多次执行，时间平均在250ms）
3、在我的开发机连服务器的数据库，执行该语句，执行结果为：（多次执行，平均时间只有35ms左右）
以上是现象。
问题是：同样的数据库，同样的表，同样的内容，同样的系统（server 2003），服务器的硬件也并不比我的开发机差，不知道为什么执行时间差这么多？
而在硬件比较差的另一台服务器上用sqlserver2000的数据库查询速度反而更快。不知道是什么原因？有人碰到过吗？
///*************/////
我的开发机profile中服务器上profile中///*************/////
数据库版本为sqlserver 2008 R2 ，补丁为sp2。
已经在多台服务器上做过测试，执行时间从七八十毫秒到五六百毫秒不等（有的硬件好的服务器执行时间反而比差的耗时还要长）。
而且就取一百多条数据，怎么会用时这么长呢？sqlserver2005和sqlserver2008 似乎同样有这个问题。而在sqlserver2000上就没有这个问题（不会超过50ms）。数据库sql server 2008 r2服务器查询效率
1、我在我的开发机执行sql语句
set statistics time on
SELECT * FROM [eShop].[dbo].[Product]（多次执行，时间平均在90-100ms）
2、在服务器上有相同的数据库，相同的表，相同的内容。执行同样SQL语句，执行结果为：（多次执行，时间平均在250ms）
3、在我的开发机连服务器的数据库，执行该语句，执行结果为：（多次执行，平均时间只有35ms左右）
以上是现象。
问题是：同样的数据库，同样的表，同样的内容，同样的系统（server 2003），服务器的硬件也并不比我的开发机差，不知道为什么执行时间差这么多？
而在硬件比较差的另一台服务器上用sqlserver2000的数据库查询速度反而更快。不知道是什么原因？有人碰到过吗？
///*************/////
我的开发机profile中服务器上profile中///*************/////
数据库版本为sqlserver 2008 R2 ，补丁为sp2。
已经在多台服务器上做过测试，执行时间从七八十毫秒到五六百毫秒不等（有的硬件好的服务器执行时间反而比差的耗时还要长）。
而且就取一百多条数据，怎么会用时这么长呢？sqlserver2005和sqlserver2008 似乎同样有这个问题。而在sqlserver2000上就没有这个问题（不会超过50ms）。数据库sql server 2008 r2服务器查询效率
#1.分别在两台机器的本地测试。排除网络因素。
#2.SET STATISTICS TIME, IO ON， 把IO也打开，看是否因为碎片等原因导致更多的逻辑读。
如果不在缓存中，那么就需要经过语法检查、语义检查、权限检查、编译，这个过程需要内存；再进行优化，生成执行计划，优化时也需要内存；然后把这个执行计划放进行缓存，这个也需要内存。3.在执行的时候，如果所要访问的数据都在内存，也就是数据也缓存在内存中了，那么就不用从硬盘读取数据，也就是没有物理IO，只有逻辑操作，速度也会快。4.在执行的时候，需要申请相关锁，如果所要访问的数据上已经加了锁，那么需要等待。5.上面几点中，还有一个问题是，系统的负载，如果系统本来就很忙，那么上面的整个过程，可能任何一步，都有可能会等待一会。另外，内存和IO非常重要，如果你的系统存在内存压力，此外，磁盘经常满负荷运转，那么计算是执行一个简单的语句，也会比负载比较低时慢。你的开发机器和你的服务器，负载是否一样。6.非常重要的一点，语句运行完成后的结果集，通过网络发送到客户端程序，所以网络是否通畅以及速度的快慢，决定了你的语句的快慢。对比，你的多张图片，之所以慢的原因应该不是在分析编译、执行时的cpu时间，而是执行时的占用时间，应该是花在IO上的，扫描次数和逻辑读取次数都一样，lob的逻辑读取差了2个，lob预读次数一样，很有可能就是这点差别，当然还有系统的负载，也会导致从硬盘读数据变慢。另外，如果是直接连接远程，可能会有网络问题，如果是像你上面，直接通过远程连接登录到数据库服务器，再直接连数据库，那么应该不是网络的问题。
SELECT a.index_id, name, avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats (DB_ID(), OBJECT_ID(N'dbo.Product'),
NULL, NULL, NULL) AS a
JOIN sys.indexes AS b ON a.object_id = b.object_id AND a.index_id = b.index_id;如果avg_fragmentation_in_percent > 30%
那么运行 alter table eShop.dbo.Product rebuild 试试
#2.从原理上讲，客户端连接取数据的速度，肯定会慢于直接在服务器上查，因为中间有一个网络传输。
#3.我怀疑，是不是2000和2005及2008计算时间的方式有所不同。
#4.楼主再做一次测试。用GETDATE()方法，分别在本机和服务器本机执行，看下时间差。
DECLARE @begin DATETIME
SET @begin = GETDATE()SELECT TOP 100 * FROM eShop.dbo.ProductSELECT DATEDIFF(millisecond, @begin, GETDATE())
#2.从原理上讲，客户端连接取数据的速度，肯定会慢于直接在服务器上查，因为中间有一个网络传输。
#3.我怀疑，是不是2000和2005及2008计算时间的方式有所不同。
#4.楼主再做一次测试。用GETDATE()方法，分别在本机和服务器本机执行，看下时间差。
DECLARE @begin DATETIME
SET @begin = GETDATE()SELECT TOP 100 * FROM eShop.dbo.ProductSELECT DATEDIFF(millisecond, @begin, GETDATE())
都是用2008 r2 执行的
试过getdate 和 set statistics time on 时间基本一致
http://bbs.csdn.net/topics/390505826?page=2
DBCC DBREINDEX ''
PREEMPTIVE_OS_WAITFORSINGLEOBJECT
NETWORK_IO
SOS_SCHEDULER_YIELD这样你就知道，到底多出来的时间，用在哪儿了
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。 SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。 SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。 SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
ProductID ProductCode PartnerID TradeID ProductName Introduction1 Weight Size PackageSize MediaUrl MediaPic Price ExpressFee1 ExpressFee2 PreviewPic1 PreviewPic2 PreviewPic2_H PreviewPic3 ShowTime OnlineTime Hits Count FreezeCount SoldCount ExchangeCount CorpPickUp RemainCount DelTime TheTime Status OperatorID1 e_ProductCode e_PartnerID e_TradeID e_ProductName e_Introduction1 e_Weight e_Size e_PackageSize e_MediaUrl e_MediaPic e_ExpressFee1 e_ExpressFee2 e_PreviewPic1 e_PreviewPic2 e_PreviewPic2_H e_PreviewPic3 e_ShowTime e_OnlineTime e_Hits e_Types e_Labels AuditTime OperatorID2 Introduction2 e_Introduction2
----------- -------------------- ----------- ----------- -------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------- -------------------------------------------------- -------------------------------------------------- ---------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------- --------------------- --------------------- --------------------- ---------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------- ------------- ---------------------------------------------------------------------------------------------------- ----------------------- ----------------------- ----------- ----------- ----------- ----------- ------------- ----------- ----------- ----------------------- ----------------------- ------ ----------- -------------------- ----------- ------------- -------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------- -------------------------------------------------- -------------------------------------------------- ---------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------- --------------------- --------------------- ---------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------- --------------- ---------------------------------------------------------------------------------------------------- ----------------------- ----------------------- ----------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------------- ----------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 001001 2 5 乾隆签名 ttt 2.5 184cm X 377cm 15cm X 15cm X 15cm NULL 10.00 0.00 0.00 /upload/product/201307/13070515031446819w365h365.gif /upload/product/201307/1307051503145bd3.gif 250 /upload/product/201307/1307051503145bd3.gif 2013-07-01 00:00:00.000 2013-08-02 00:00:00.000 1 1000 55 0 1 0 8 2013-09-01 00:00:00.000 2013-07-01 00:00:00.000 2 1 001001 2 5 test 2.5 15cm X 15cm 15cm X 15cm X 15cm NULL 0.00 0.00 1307011636331.jpg 1307011636332.jpg 250 1307011636333.jpg 2013-07-01 12:00:00.000 2013-07-02 12:00:00.000 12 1,2 2,3 NULL NULL NULL test
//************省略99行**********//
(100 行受影响)表 'Product'。扫描计数 1，逻辑读取 10 次，物理读取 0 次，预读 0 次，lob 逻辑读取 245 次，lob 物理读取 0 次，lob 预读 2 次。
-------------------- -------------------- ------------------------------------------------------------------------------ ----------- ----------- ----------- ------------------------------ ------------------------------ ---------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------------- ------------- ------------- ----------- ---------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -------- ---------------------------------------------------------------- -------- ------------------
100 1 select top 100 *from product
--select @@SPID 1 1 0 NULL NULL NULL NULL 100 NULL NULL NULL 0.00899522 NULL NULL SELECT 0 NULL
100 1 |--Top(TOP EXPRESSION:((100))) 1 2 1 Top Top TOP EXPRESSION:((100)) NULL 100 0 1E-05 1552 0.00899522 [eShop].[dbo].[Product].[ProductID], [eShop].[dbo].[Product].[ProductCode], [eShop].[dbo].[Product].[PartnerID], [eShop].[dbo].[Product].[TradeID], [eShop].[dbo].[Product].[ProductName], [eShop].[dbo].[Product].[Introduction1], [eShop].[dbo].[Product]. NULL PLAN_ROW 0 1
100 1 |--Clustered Index Scan(OBJECT:([eShop].[dbo].[Product].[PK_Product])) 1 3 2 Clustered Index Scan Clustered Index Scan OBJECT:([eShop].[dbo].[Product].[PK_Product]) [eShop].[dbo].[Product].[ProductID], [eShop].[dbo].[Product].[ProductCode], [eShop].[dbo].[Product].[PartnerID], [eShop].[dbo].[Product].[TradeID], [eShop].[dbo].[Product].[ProductName], [eShop].[dbo].[Product].[Introduction1], [eShop].[dbo].[Product]. 100 0.009791667 0.0002879 1552 0.00898522 [eShop].[dbo].[Product].[ProductID], [eShop].[dbo].[Product].[ProductCode], [eShop].[dbo].[Product].[PartnerID], [eShop].[dbo].[Product].[TradeID], [eShop].[dbo].[Product].[ProductName], [eShop].[dbo].[Product].[Introduction1], [eShop].[dbo].[Product]. NULL PLAN_ROW 0 1(3 行受影响)
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 27 毫秒。
表 'sysclsobjs'。扫描计数 1，逻辑读取 2 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
Rows Executes StmtText StmtId NodeId Parent PhysicalOp LogicalOp Argument DefinedValues EstimateRows EstimateIO EstimateCPU AvgRowSize TotalSubtreeCost OutputList Warnings Type Parallel EstimateExecutions
-------------------- -------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------- ----------- ----------- ------------------------------ ------------------------------ --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------ ------------- ------------- ------------- ----------- ---------------- ----------- -------- ---------------------------------------------------------------- -------- ------------------
100 1 select top 100 *from product
--select @@SPID 1 1 0 NULL NULL NULL NULL 100 NULL NULL NULL 0.00899522 NULL NULL SELECT 0 NULL
100 1 |--Top(TOP EXPRESSION:((100))) 1 2 1 Top Top TOP EXPRESSION:((100)) NULL 100 0 1E-05 1552 0.00899522 [eShop].[dbo].[Product].[ProductID], [eShop].[dbo].[Product].[ProductCode], [eShop].[dbo].[Product].[PartnerID], [eShop].[dbo].[Product].[TradeID], [eShop].[dbo].[Product].[ProductName], [eShop].[dbo].[Product].[Introduction1], [eShop].[dbo].[Product]. NULL PLAN_ROW 0 1
100 1 |--Clustered Index Scan(OBJECT:([eShop].[dbo].[Product].[PK_Product])) 1 3 2 Clustered Index Scan Clustered Index Scan OBJECT:([eShop].[dbo].[Product].[PK_Product]) [eShop].[dbo].[Product].[ProductID], [eShop].[dbo].[Product].[ProductCode], [eShop].[dbo].[Product].[PartnerID], [eShop].[dbo].[Product].[TradeID], [eShop].[dbo].[Product].[ProductName], [eShop].[dbo].[Product].[Introduction1], [eShop].[dbo].[Product]. 100 0.009791667 0.0002879 1552 0.00898522 [eShop].[dbo].[Product].[ProductID], [eShop].[dbo].[Product].[ProductCode], [eShop].[dbo].[Product].[PartnerID], [eShop].[dbo].[Product].[TradeID], [eShop].[dbo].[Product].[ProductName], [eShop].[dbo].[Product].[Introduction1], [eShop].[dbo].[Product]. NULL PLAN_ROW 0 1(3 行受影响)
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 27 毫秒。
表 'sysclsobjs'。扫描计数 1，逻辑读取 2 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
Rows Executes StmtText StmtId NodeId Parent PhysicalOp LogicalOp Argument DefinedValues EstimateRows EstimateIO EstimateCPU AvgRowSize TotalSubtreeCost OutputList Warnings Type Parallel EstimateExecutions
-------------------- -------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------- ----------- ----------- ------------------------------ ------------------------------ --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------ ------------- ------------- ------------- ----------- ---------------- ----------- -------- ---------------------------------------------------------------- -------- ------------------
1 1 IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='Waits_of_Particular_Session') 2 1 0 NULL NULL NULL NULL 1 NULL NULL NULL 0.003289617 NULL NULL GeneralQuery 0 NULL
0 0 |--Compute Scalar(DEFINE:([Expr1019]=CASE WHEN [Expr1021] THEN (1) ELSE (0) END)) 2 2 1 Compute Scalar Compute Scalar DEFINE:([Expr1019]=CASE WHEN [Expr1021] THEN (1) ELSE (0) END) [Expr1019]=CASE WHEN [Expr1021] THEN (1) ELSE (0) END 1 0 1E-07 11 0.003289617 [Expr1019] NULL PLAN_ROW 0 1
1 1 |--Nested Loops(Left Semi Join, DEFINE:([Expr1021] = [PROBE VALUE])) 2 3 2 Nested Loops Left Semi Join DEFINE:([Expr1021] = [PROBE VALUE]) [Expr1021] = [PROBE VALUE] 1 0 4.18E-06 9 0.003289517 [Expr1021] NULL PLAN_ROW 0 1
1 1 |--Constant Scan 2 4 3 Constant Scan Constant Scan NULL NULL 1 0 1.157E-06 9 1.157E-06 NULL NULL PLAN_ROW 0 1
1 1 |--Filter(WHERE:(STARTUP EXPR(has_access('ES',(0))=(1)))) 2 6 3 Filter Filter WHERE:(STARTUP EXPR(has_access('ES',(0))=(1))) NULL 1 0 9.8E-07 9 0.00328408 NULL NULL PLAN_ROW 0 1
1 1 |--Clustered Index Seek(OBJECT:([master].[sys].[sysclsobjs].[clst] AS [c]), SEEK:([c].[class]=(62)), WHERE:(CONVERT(nvarchar(128),[master].[sys].[sysclsobjs].[name] as [c].[name],0)=N'Waits_of_Particular_Session') ORDERED FORWARD) 2 7 6 Clustered Index Seek Clustered Index Seek OBJECT:([master].[sys].[sysclsobjs].[clst] AS [c]), SEEK:([c].[class]=(62)), WHERE:(CONVERT(nvarchar(128),[master].[sys].[sysclsobjs].[name] as [c].[name],0)=N'Waits_of_Particular_Session') ORDERED FORWARD NULL 1 0.003125 0.0001581 34 0.0032831 NULL NULL PLAN_ROW 0 1(6 行受影响)
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
是这样吧？
GOOD,
大部分时间用在NETWORK_IO上，很明显是网络的问题。
是这样吧？
GOOD,
大部分时间用在NETWORK_IO上，很明显是网络的问题。可我是在服务器本机是执行的啊
是这样吧？
GOOD,
大部分时间用在NETWORK_IO上，很明显是网络的问题。
可我是在服务器本机是执行的啊
我上面说的网路问题可以理解为：服务器端SQL SERVER 到client application SSMS之间的延时)。SQL SERVER引擎每发送一行数据给SSMS,就需要SSMS给SQL SERVER引擎一个反馈，表面SSMS已经收到。不同版本的SSMS确实在处理这个问题时确实会有不同的表现。
我曾经用SSMS2012跟SSMS2008对比，差了不止一个数量级。
是这样吧？
GOOD,
大部分时间用在NETWORK_IO上，很明显是网络的问题。
可我是在服务器本机是执行的啊
我上面说的网路问题可以理解为：服务器端SQL SERVER 到client application SSMS之间的延时)。SQL SERVER引擎每发送一行数据给SSMS,就需要SSMS给SQL SERVER引擎一个反馈，表面SSMS已经收到。不同版本的SSMS确实在处理这个问题时确实会有不同的表现。
现在我用同一个版本的sqlserver2008r2，进行的三组测试，开发机连服务器用时最短，开发机第二，直接在服务器上执行最慢，这个可以解释的通吗？
这个就是SSMS的问题，不是所有的SSMS都这样的，
另外，你自己可以写个.NET程序，测试把数据从数据库取到datatable里需要的时间，这可以排除SSMS的干扰。
这个就是SSMS的问题，不是所有的SSMS都这样的，
另外，你自己可以写个.NET程序，测试把数据从数据库取到datatable里需要的时间，这可以排除SSMS的干扰。
在服务器上点击testSQL按钮 第一次第二次
第三次
以后再点就在2 3次结果中变化
这个就是SSMS的问题，不是所有的SSMS都这样的，
另外，你自己可以写个.NET程序，测试把数据从数据库取到datatable里需要的时间，这可以排除SSMS的干扰。
在服务器上点击testSQL按钮 第一次第二次
第三次
以后再点就在2 3次结果中变化
从图上看第二次用了31.25毫秒，第三次用了15.625毫秒，然后在之间徘徊，从这个数据库来看，应该是已经排除了SSMS的干扰了。
不过你的间隔时间似乎跟结束时间与开始时间之间的差值不对应啊。
不过你的间隔时间似乎跟结束时间与开始时间之间的差值不对应啊。
看这个，第一次
第二次第三次
不过你的间隔时间似乎跟结束时间与开始时间之间的差值不对应啊。
这个时间是 显示有问题 应该是 218-031=187 ，差值是没错的
不过你的间隔时间似乎跟结束时间与开始时间之间的差值不对应啊。
这个时间是 显示有问题 应该是 218-031=187 ，差值是没错的那就非常make sense了。
结论如下：
1，从用XE测试来看，时间消耗在Network_IO，由于SSMS跟SQL SERVER在同一个服务器上，所以这是SSMS产生的问题（一般来说，每个版本的数据库引擎的性能都会有所增加，SSMS到不一定）。
2，去掉SSMS，直接用WINFORM来测试，时间从几百毫秒降到15~32毫秒，这就证明了是SSMS处理数据的问题。
3，WINFORM的第一次测试花了187毫秒，也很正常，因为第一次要建立物理数据链接，以其数据库端第一次操作的消耗（PLAN跟物理IO等）。
根据你的结论，如果说是ssms有问题，导致使用ssms查询数据的时间要大于直接用winform的话。
那么，1：我使用我开发机上同一个ssms 连服务器执行查询的时间,反而比我直接查询我本机的时间要短，这个怎么解释呢?（从原理上来说查询本机肯定要比查服务器快的啊）
2：如果微软提供的数据库引擎没有问题，而给出的ssms却是有问题的。要我们开发人员怎样进行数据库监测和优化？（因为在server profile里的duration时间是和ssms一致的），难道也要自己写个winform来？这样微软不是太坑了？
根据你的结论，如果说是ssms有问题，导致使用ssms查询数据的时间要大于直接用winform的话。
那么，1：我使用我开发机上同一个ssms 连服务器执行查询的时间,反而比我直接查询我本机的时间要短，这个怎么解释呢?（从原理上来说查询本机肯定要比查服务器快的啊）
2：如果微软提供的数据库引擎没有问题，而给出的ssms却是有问题的。要我们开发人员怎样进行数据库监测和优化？（因为在server profile里的duration时间是和ssms一致的），难道也要自己写个winform来？这样微软不是太坑了？
1，测试的结果不是已经很明显是SSMS的问题了嘛，你用SSMS，200多毫秒，不用SSMS， 15-30毫秒。这还有什么争议吗？
2，无所谓的，就这么几百毫秒的影响对你总体的数据库监测和优化产生的影响可以忽略不计，而且你能用SSMS能监控什么？最多就是查查语句摆了。当然，如果你确实认为SSMS的那个东西影响了你，你可以向微软提交BUG
https://connect.microsoft.com/SQLServer/Feedback
http://social.technet.microsoft.com/Forums/zh-CN/03a32672-5443-4fd1-b231-f9af9b71ce44/sql-server-2008-?prof=required
msdn上的帖子也是我发的，两位大神是不是可以就在这个论坛讨论呢？
还有您的意思是 先进行一下操作
更新统计信息USE [GPOSDB]
GO
UPDATE STATISTICS CT_FuelingData
UPDATE STATISTICS CT_InhouseCard
GO
清空缓冲DBCC DROPCLEANBUFFERS
GO
DBCC FREEPROCCACHE
GO
ALTER INDEX REBUILD语句重建索引，保证没有索引碎片
在进行测试的结果就是比较准确的了吗？
msdn上的帖子也是我发的，两位大神是不是可以就在这个论坛讨论呢？
还有您的意思是 先进行一下操作
更新统计信息USE [GPOSDB]
GO
UPDATE STATISTICS CT_FuelingData
UPDATE STATISTICS CT_InhouseCard
GO
清空缓冲DBCC DROPCLEANBUFFERS
GO
DBCC FREEPROCCACHE
GO
ALTER INDEX REBUILD语句重建索引，保证没有索引碎片
在进行测试的结果就是比较准确的了吗？
我不会再讨论，数据摆在那里，我觉得没有什么可争议的
其实C#有没有set statistics time on并不重要，SQL Server有种优化性能的方法学：YAPP，Response time = service time + wait time换句话说，无论是locking,latch, CPU, network,...等等任何因素造成的性能问题，都逃不过通过XE来捕获等待事件的 wait statistics，而XE的结果很明显显示了：时间是用在了network_io上（223MS），由于SSMS在本地，那就不是网络传输问题了，而是SSMS本身的显示问题了， make sense? 这是您的回复吗？
我后来修改了一下程序又进行了新的测试（因为在ssms里数据时显示出来的，而我原来的程序只取了行数没有进行数据显示），新的三组测试结果如下：
1.直接在.4服务器上运行程序连.4数据库：
第一次：
第二次：
基本维持在这个结果，最快出现过
2.直接在我的开发机运行程序连本机数据库：
第一次：
第二次：
基本维持这个值，偶尔出现
3.在我的开发机运行程序连.4数据库：
第一次：
第二次：
这个结果应该和ssms里的时间在同一数量级了
其实你的上面实验再次证明了是UI显示的问题，换句话说，如果是用SSMS的时候，是SSMS那个UI在显示的时候由于某个因素导致在服务器上那个SSMS在显示表格的时候比你在本地的慢，这个有很多因素的，我听说过某个显示器或者它的分别率都能影响SSMS打印那个数据表格的速度。我说了，这个问题其实对你性能优化，监控什么的，影响不大，
当然如果你确实对那个问题很敢兴趣， 你跟微软CSS联系一下，让他们给你做个case，debugging一下，ETW tracking一下，看看时间花在SSMS里面的哪个函数上面，OKAY?
您原来给的结论不是时间在network_io上么？意思是这个ui显示会算在那个network_io的时间里吗？
这个问题最早就是在profile里监控到的，profile里的duration时间和set statistics time on 时间是一致的。
微软的话，人家正忙着选ceo呢，还是先不麻烦人家了吧！
您原来给的结论不是时间在network_io上么？意思是这个ui显示会算在那个network_io的时间里吗？
这个问题最早就是在profile里监控到的，profile里的duration时间和set statistics time on 时间是一致的。
微软的话，人家正忙着选ceo呢，还是先不麻烦人家了吧！"您原来给的结论不是时间在network_io上么？"
是的，
"意思是这个ui显示会算在那个network_io的时间里吗？"
当然！
大名鼎鼎有点过了，本人在sqlserver领域还是刚刚起步