SQL Server 2008 r2 查询效率问题

我有一张表，共有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）。

55 个解决方案

#1

先看下各个机器上的实际执行计划。有什么不同吗？

#2

开发机：
服务器：

#3

引用 2 楼 iammrwu 的回复:

开发机
服务器

执行计划一样，再测试一下，要点：
#1.分别在两台机器的本地测试。排除网络因素。
#2.SET STATISTICS TIME, IO ON， 把IO也打开，看是否因为碎片等原因导致更多的逻辑读。

#4

引用

wwwwgou

#5

从表面看，很难分析出为什么多台机器执行同一个简单的sql语句，速度有差异，甚至好的服务器反而花了更多的时间，而看上去相对较差的机器反而更快，这些都是表面现象。

我们可以分析一下整个SQL语句执行的大致过程：

1.语句发送到SQL Server服务器端。

2.SQL Server会找这个语句是否已经缓存在内存中，如果能找到，这样就不用重新编译，这样就会节省时间。
如果不在缓存中，那么就需要经过语法检查、语义检查、权限检查、编译，这个过程需要内存；再进行优化，生成执行计划，优化时也需要内存；然后把这个执行计划放进行缓存，这个也需要内存。

3.在执行的时候，如果所要访问的数据都在内存，也就是数据也缓存在内存中了，那么就不用从硬盘读取数据，也就是没有物理IO，只有逻辑操作，速度也会快。

4.在执行的时候，需要申请相关锁，如果所要访问的数据上已经加了锁，那么需要等待。

5.上面几点中，还有一个问题是，系统的负载，如果系统本来就很忙，那么上面的整个过程，可能任何一步，都有可能会等待一会。另外，内存和IO非常重要，如果你的系统存在内存压力，此外，磁盘经常满负荷运转，那么计算是执行一个简单的语句，也会比负载比较低时慢。

你的开发机器和你的服务器，负载是否一样。

6.非常重要的一点，语句运行完成后的结果集，通过网络发送到客户端程序，所以网络是否通畅以及速度的快慢，决定了你的语句的快慢。

对比，你的多张图片，之所以慢的原因应该不是在分析编译、执行时的cpu时间，而是执行时的占用时间，应该是花在IO上的，扫描次数和逻辑读取次数都一样，lob的逻辑读取差了2个，lob预读次数一样，很有可能就是这点差别，当然还有系统的负载，也会导致从硬盘读数据变慢。

另外，如果是直接连接远程，可能会有网络问题，如果是像你上面，直接通过远程连接登录到数据库服务器，再直接连数据库，那么应该不是网络的问题。

#6

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 试试

#7

引用 4 楼 iammrwu 的回复:

引用

wwwwgou

#1.第一张是本机执行（2000是吧？），第二张图是在服务器执行（2005或2008），第三张图是本机连服务器。结果1和3快（内网吧？网速忽略不计，时间几乎相同），2慢。
#2.从原理上讲，客户端连接取数据的速度，肯定会慢于直接在服务器上查，因为中间有一个网络传输。
#3.我怀疑，是不是2000和2005及2008计算时间的方式有所不同。
#4.楼主再做一次测试。用GETDATE()方法，分别在本机和服务器本机执行，看下时间差。

DECLARE @begin DATETIME
SET @begin  = GETDATE()

SELECT TOP 100 * FROM eShop.dbo.Product

SELECT DATEDIFF(millisecond, @begin, GETDATE())

#8

有很多原因，只是查询TOP 100可能没有意义。 

#9

引用 6 楼 yupeigu 的回复:

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 试试

执行前
执行后
好像没什么变化

#10

引用 7 楼 wwwwgou 的回复:

Quote: 引用 4 楼 iammrwu 的回复:

引用

wwwwgou

#1.第一张是本机执行（2000是吧？），第二张图是在服务器执行（2005或2008），第三张图是本机连服务器。结果1和3快（内网吧？网速忽略不计，时间几乎相同），2慢。
#2.从原理上讲，客户端连接取数据的速度，肯定会慢于直接在服务器上查，因为中间有一个网络传输。
#3.我怀疑，是不是2000和2005及2008计算时间的方式有所不同。
#4.楼主再做一次测试。用GETDATE()方法，分别在本机和服务器本机执行，看下时间差。

DECLARE @begin DATETIME
SET @begin  = GETDATE()

SELECT TOP 100 * FROM eShop.dbo.Product

SELECT DATEDIFF(millisecond, @begin, GETDATE())

都是用2008 r2 执行的
试过getdate 和 set statistics time on 时间基本一致

#11

引用 8 楼 SmithLiu328 的回复:

有很多原因，只是查询TOP 100可能没有意义。 

已经在好多服务器上都试过了，都是这样的结果（时间虽有变化，但是都比较长），只是这么个简单的查询就要这么长时间肯定不正常吧，你觉得怎样做会好些呢？

#12

引用 10 楼 iammrwu 的回复:

都是用2008 r2 执行的
试过getdate 和 set statistics time on 时间基本一致

帮顶，哪位大侠能解释一下？

#13

如果你觉得那个几百毫秒的语句有问题，那你按下面帖子中103楼的做法，把结果贴出来，看看时间到底花在哪里？
http://bbs.csdn.net/topics/390505826?page=2

#14

开发机和服务器的负载不一样，数据量不一样，索引碎片程度不一样，数据缓存情况不一样

看你贴的索引碎片不少，先整理下索引碎片吧
DBCC DBREINDEX ''

#15

试试用13楼的办法，其实就是能明确区分这些时间：

PAGEIOLATCH_SH
PREEMPTIVE_OS_WAITFORSINGLEOBJECT
NETWORK_IO
SOS_SCHEDULER_YIELD

这样你就知道，到底多出来的时间，用在哪儿了

#16

SQL Server 分析和编译时间: 
   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   TrademarkID 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_TrademarkID 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 次。

#17

引用 13 楼 SQL_Beginner 的回复:

如果你觉得那个几百毫秒的语句有问题，那你按下面帖子中103楼的做法，把结果贴出来，看看时间到底花在哪里？
http://bbs.csdn.net/topics/390505826?page=2

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].[TrademarkID], [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].[TrademarkID], [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].[TrademarkID], [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
-------------------- -------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------- ----------- ----------- ------------------------------ ------------------------------ --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------ ------------- ------------- ------------- ----------- ---------------- ----------- -------- ---------------------------------------------------------------- -------- ------------------

#18

引用 17 楼 iammrwu 的回复:

Quote: 引用 13 楼 SQL_Beginner 的回复:

如果你觉得那个几百毫秒的语句有问题，那你按下面帖子中103楼的做法，把结果贴出来，看看时间到底花在哪里？
http://bbs.csdn.net/topics/390505826?page=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].[TrademarkID], [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].[TrademarkID], [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].[TrademarkID], [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 毫秒。

#19

1,这个是你在那个有问题的，跑了几百ms的机器上做的吗？select top 100 *from product 的statistics time是多少？我怎么没有看到。 0ms吗?

2，你漏了一个重要东西，请给出我上面贴出那个URL的103楼，section 2.3 的结果。

#20

1.所有的IO都是逻辑读，没有物理读，说明数据都被缓存在内存中了
2.根据执行计划，聚集索引扫描的开销最大,因此结合1，说明时间主要消耗在扫描索引上，那么通过重建索引减少索引页数，应该是最佳的调优策略

#21

引用 19 楼 SQL_Beginner 的回复:

1,这个是你在那个有问题的，跑了几百ms的机器上做的吗？select top 100 *from product 的statistics time是多少？我怎么没有看到。 0ms吗?

2，你漏了一个重要东西，请给出我上面贴出那个URL的103楼，section 2.3 的结果。

#22

引用 15 楼 yupeigu 的回复:

试试用13楼的办法，其实就是能明确区分这些时间：

PAGEIOLATCH_SH
PREEMPTIVE_OS_WAITFORSINGLEOBJECT
NETWORK_IO
SOS_SCHEDULER_YIELD

这样你就知道，到底多出来的时间，用在哪儿了

您也帮我看看

#23

引用 21 楼 iammrwu 的回复:

Quote: 引用 19 楼 SQL_Beginner 的回复:

1,这个是你在那个有问题的，跑了几百ms的机器上做的吗？select top 100 *from product 的statistics time是多少？我怎么没有看到。 0ms吗?

2，你漏了一个重要东西，请给出我上面贴出那个URL的103楼，section 2.3 的结果。

是这样吧？

#24

引用 23 楼 iammrwu 的回复:

Quote: 引用 21 楼 iammrwu 的回复:

Quote: 引用 19 楼 SQL_Beginner 的回复:

1,这个是你在那个有问题的，跑了几百ms的机器上做的吗？select top 100 *from product 的statistics time是多少？我怎么没有看到。 0ms吗?

2，你漏了一个重要东西，请给出我上面贴出那个URL的103楼，section 2.3 的结果。

是这样吧？

GOOD,
大部分时间用在NETWORK_IO上，很明显是网络的问题。

#25

引用 24 楼 SQL_Beginner 的回复:

Quote: 引用 23 楼 iammrwu 的回复:

Quote: 引用 21 楼 iammrwu 的回复:

Quote: 引用 19 楼 SQL_Beginner 的回复:

1,这个是你在那个有问题的，跑了几百ms的机器上做的吗？select top 100 *from product 的statistics time是多少？我怎么没有看到。 0ms吗?

2，你漏了一个重要东西，请给出我上面贴出那个URL的103楼，section 2.3 的结果。

是这样吧？

GOOD,
大部分时间用在NETWORK_IO上，很明显是网络的问题。

可我是在服务器本机是执行的啊 

#26

引用 25 楼 iammrwu 的回复:

Quote: 引用 24 楼 SQL_Beginner 的回复:

Quote: 引用 23 楼 iammrwu 的回复:

Quote: 引用 21 楼 iammrwu 的回复:

Quote: 引用 19 楼 SQL_Beginner 的回复:

1,这个是你在那个有问题的，跑了几百ms的机器上做的吗？select top 100 *from product 的statistics time是多少？我怎么没有看到。 0ms吗?

2，你漏了一个重要东西，请给出我上面贴出那个URL的103楼，section 2.3 的结果。

是这样吧？

GOOD,
大部分时间用在NETWORK_IO上，很明显是网络的问题。

可我是在服务器本机是执行的啊 

我上面说的网路问题可以理解为：服务器端SQL SERVER 到client application SSMS之间的延时)。SQL SERVER引擎每发送一行数据给SSMS,就需要SSMS给SQL SERVER引擎一个反馈，表面SSMS已经收到。不同版本的SSMS确实在处理这个问题时确实会有不同的表现。

#27

呵呵，网络问题，真是出乎意料之外，之前我也碰到一次这种问题，百思不得其解，

这个网络问题和我的那个问题还不完全一样，我的那个应该是下行速度慢，但也有可能是上行速度慢，就和你用迅雷下载文件时是一样的，每次SQL Server把结果集的一部分发送到客户端应用程序，客户端接收到后都需要反馈一样，意思就是我收到了，所以有2类问题，可能是下载慢，可能是上传慢，当然也有可能是上面说的因为不同版本导致的问题。

#28

引用 27 楼 yupeigu 的回复:

呵呵，网络问题，真是出乎意料之外，之前我也碰到一次这种问题，百思不得其解，

这个网络问题和我的那个问题还不完全一样，我的那个应该是下行速度慢，但也有可能是上行速度慢，就和你用迅雷下载文件时是一样的，每次SQL Server把结果集的一部分发送到客户端应用程序，客户端接收到后都需要反馈一样，意思就是我收到了，所以有2类问题，可能是下载慢，可能是上传慢，当然也有可能是上面说的因为不同版本导致的问题。

嗯，遇到过一个极端的例子，同样的一个语句，数据也一样 ，
我曾经用SSMS2012跟SSMS2008对比，差了不止一个数量级。

#29

会不是是协议的问题呢？

#30

路过学习

#31

引用 26 楼 SQL_Beginner 的回复:

Quote: 引用 25 楼 iammrwu 的回复:

Quote: 引用 24 楼 SQL_Beginner 的回复:

Quote: 引用 23 楼 iammrwu 的回复:

Quote: 引用 21 楼 iammrwu 的回复:

Quote: 引用 19 楼 SQL_Beginner 的回复:

1,这个是你在那个有问题的，跑了几百ms的机器上做的吗？select top 100 *from product 的statistics time是多少？我怎么没有看到。 0ms吗?

2，你漏了一个重要东西，请给出我上面贴出那个URL的103楼，section 2.3 的结果。

是这样吧？

GOOD,
大部分时间用在NETWORK_IO上，很明显是网络的问题。

可我是在服务器本机是执行的啊 

我上面说的网路问题可以理解为：服务器端SQL SERVER 到client application SSMS之间的延时)。SQL SERVER引擎每发送一行数据给SSMS,就需要SSMS给SQL SERVER引擎一个反馈，表面SSMS已经收到。不同版本的SSMS确实在处理这个问题时确实会有不同的表现。

现在我用同一个版本的sqlserver2008r2，进行的三组测试，开发机连服务器用时最短，开发机第二，直接在服务器上执行最慢，这个可以解释的通吗？

#32

引用 27 楼 yupeigu 的回复:

呵呵，网络问题，真是出乎意料之外，之前我也碰到一次这种问题，百思不得其解，

这个网络问题和我的那个问题还不完全一样，我的那个应该是下行速度慢，但也有可能是上行速度慢，就和你用迅雷下载文件时是一样的，每次SQL Server把结果集的一部分发送到客户端应用程序，客户端接收到后都需要反馈一样，意思就是我收到了，所以有2类问题，可能是下载慢，可能是上传慢，当然也有可能是上面说的因为不同版本导致的问题。

这个network_io占用这么长时间有什么方法优化吗？还有个问题就是我查询前十条时间是0ms，

而查询11条就瞬间提升到80ms

这个又是怎么回事？

#33

请看清楚是毫秒不是秒，在提示一下没执行一次 在执行下一次的时候先清除掉上次的执行计划 然后再换个方式执行 看看  执行计划 有何变动  再取 找寻问题；

#34

引用 32 楼 iammrwu 的回复:

Quote: 引用 27 楼 yupeigu 的回复:

呵呵，网络问题，真是出乎意料之外，之前我也碰到一次这种问题，百思不得其解，

这个网络问题和我的那个问题还不完全一样，我的那个应该是下行速度慢，但也有可能是上行速度慢，就和你用迅雷下载文件时是一样的，每次SQL Server把结果集的一部分发送到客户端应用程序，客户端接收到后都需要反馈一样，意思就是我收到了，所以有2类问题，可能是下载慢，可能是上传慢，当然也有可能是上面说的因为不同版本导致的问题。

这个network_io占用这么长时间有什么方法优化吗？还有个问题就是我查询前十条时间是0ms，

而查询11条就瞬间提升到80ms

这个又是怎么回事？

这个就是SSMS的问题，不是所有的SSMS都这样的，
另外，你自己可以写个.NET程序，测试把数据从数据库取到datatable里需要的时间，这可以排除SSMS的干扰。

#35

引用 34 楼 SQL_Beginner 的回复:

Quote: 引用 32 楼 iammrwu 的回复:

Quote: 引用 27 楼 yupeigu 的回复:

呵呵，网络问题，真是出乎意料之外，之前我也碰到一次这种问题，百思不得其解，

这个网络问题和我的那个问题还不完全一样，我的那个应该是下行速度慢，但也有可能是上行速度慢，就和你用迅雷下载文件时是一样的，每次SQL Server把结果集的一部分发送到客户端应用程序，客户端接收到后都需要反馈一样，意思就是我收到了，所以有2类问题，可能是下载慢，可能是上传慢，当然也有可能是上面说的因为不同版本导致的问题。

这个network_io占用这么长时间有什么方法优化吗？还有个问题就是我查询前十条时间是0ms，

而查询11条就瞬间提升到80ms

这个又是怎么回事？

这个就是SSMS的问题，不是所有的SSMS都这样的，
另外，你自己可以写个.NET程序，测试把数据从数据库取到datatable里需要的时间，这可以排除SSMS的干扰。

在服务器上点击testSQL按钮  第一次

第二次 
第三次 
以后再点就在2 3次结果中变化

#36

引用 35 楼 iammrwu 的回复:

Quote: 引用 34 楼 SQL_Beginner 的回复:

Quote: 引用 32 楼 iammrwu 的回复:

Quote: 引用 27 楼 yupeigu 的回复:

呵呵，网络问题，真是出乎意料之外，之前我也碰到一次这种问题，百思不得其解，

这个网络问题和我的那个问题还不完全一样，我的那个应该是下行速度慢，但也有可能是上行速度慢，就和你用迅雷下载文件时是一样的，每次SQL Server把结果集的一部分发送到客户端应用程序，客户端接收到后都需要反馈一样，意思就是我收到了，所以有2类问题，可能是下载慢，可能是上传慢，当然也有可能是上面说的因为不同版本导致的问题。

这个network_io占用这么长时间有什么方法优化吗？还有个问题就是我查询前十条时间是0ms，

而查询11条就瞬间提升到80ms

这个又是怎么回事？

这个就是SSMS的问题，不是所有的SSMS都这样的，
另外，你自己可以写个.NET程序，测试把数据从数据库取到datatable里需要的时间，这可以排除SSMS的干扰。

在服务器上点击testSQL按钮  第一次

第二次 
第三次 
以后再点就在2 3次结果中变化

从图上看第二次用了31.25毫秒，第三次用了15.625毫秒，然后在之间徘徊，从这个数据库来看，应该是已经排除了SSMS的干扰了。
不过你的间隔时间似乎跟结束时间与开始时间之间的差值不对应啊。

#37

引用 36 楼 SQL_Beginner 的回复:

Quote: 引用 35 楼 iammrwu 的回复:

Quote: 引用 34 楼 SQL_Beginner 的回复:

Quote: 引用 32 楼 iammrwu 的回复:

Quote: 引用 27 楼 yupeigu 的回复:

呵呵，网络问题，真是出乎意料之外，之前我也碰到一次这种问题，百思不得其解，

这个网络问题和我的那个问题还不完全一样，我的那个应该是下行速度慢，但也有可能是上行速度慢，就和你用迅雷下载文件时是一样的，每次SQL Server把结果集的一部分发送到客户端应用程序，客户端接收到后都需要反馈一样，意思就是我收到了，所以有2类问题，可能是下载慢，可能是上传慢，当然也有可能是上面说的因为不同版本导致的问题。

从图上看第二次用了31.25毫秒，第三次用了15.625毫秒，然后在之间徘徊，从这个数据库来看，应该是已经排除了SSMS的干扰了。
不过你的间隔时间似乎跟结束时间与开始时间之间的差值不对应啊。

看这个，第一次
第二次 第三次

#38

引用 36 楼 SQL_Beginner 的回复:

在服务器上点击testSQL按钮  第一次

以后再点就在2 3次结果中变化

从图上看第二次用了31.25毫秒，第三次用了15.625毫秒，然后在之间徘徊，从这个数据库来看，应该是已经排除了SSMS的干扰了。
不过你的间隔时间似乎跟结束时间与开始时间之间的差值不对应啊。
这个时间是 显示有问题 应该是 218-031=187  ，差值是没错的

#39

引用 38 楼 iammrwu 的回复:

Quote: 引用 36 楼 SQL_Beginner 的回复:

在服务器上点击testSQL按钮  第一次

以后再点就在2 3次结果中变化

从图上看第二次用了31.25毫秒，第三次用了15.625毫秒，然后在之间徘徊，从这个数据库来看，应该是已经排除了SSMS的干扰了。
不过你的间隔时间似乎跟结束时间与开始时间之间的差值不对应啊。

这个时间是 显示有问题 应该是 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等）。

#40

引用 39 楼 SQL_Beginner 的回复:

那就非常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来？这样微软不是太坑了？

#41

引用 40 楼 iammrwu 的回复:

Quote: 引用 39 楼 SQL_Beginner 的回复:

那就非常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来？这样微软不是太坑了？

1，测试的结果不是已经很明显是SSMS的问题了嘛，你用SSMS，200多毫秒，不用SSMS， 15-30毫秒。这还有什么争议吗？
2，无所谓的，就这么几百毫秒的影响对你总体的数据库监测和优化产生的影响可以忽略不计，而且你能用SSMS能监控什么？最多就是查查语句摆了。

当然，如果你确实认为SSMS的那个东西影响了你，你可以向微软提交BUG
https://connect.microsoft.com/SQLServer/Feedback

#42

顶一下，不要沉

#43

还有LZ说SSMS有问题，本人觉得不是SSMS的问题

因为winform跟SSMS统计的时间是不一样的

想知道LZ在winform里统计sql执行时间的代码是怎么写的

SSMS就只有set statistics time on，而C#是没有set statistics time on的

既然winform跟SSMS的测试前提条件都不平等，何来一样的结果呢？？？

#44

我在这个帖子已经回复您了LZ
http://social.technet.microsoft.com/Forums/zh-CN/03a32672-5443-4fd1-b231-f9af9b71ce44/sql-server-2008-?prof=required

#45

引用 44 楼 lyhab 的回复:

我在这个帖子已经回复您了LZ
http://social.technet.microsoft.com/Forums/zh-CN/03a32672-5443-4fd1-b231-f9af9b71ce44/sql-server-2008-?prof=required

这不是官网里大名鼎鼎的华仔嘛，看得出你对SQL SERVER很有激情啊（虽然技术有待加强 ），既然来了，就好好的为这里的兄弟服务服务吧，千万别轻易离开啊，你看你在官网，一天到晚没几个帖子，寂寞不？ 这里有你发挥的。一直在那里冷冷清清的，怕影响你的激情

#46

引用 43 楼 lyhab 的回复:

还有LZ说SSMS有问题，本人觉得不是SSMS的问题

因为winform跟SSMS统计的时间是不一样的

想知道LZ在winform里统计sql执行时间的代码是怎么写的

SSMS就只有set statistics time on，而C#是没有set statistics time on的

既然winform跟SSMS的测试前提条件都不平等，何来一样的结果呢？？？

官网上一家给你回复了。

#47

引用 43 楼 lyhab 的回复:

还有LZ说SSMS有问题，本人觉得不是SSMS的问题

因为winform跟SSMS统计的时间是不一样的

想知道LZ在winform里统计sql执行时间的代码是怎么写的

SSMS就只有set statistics time on，而C#是没有set statistics time on的

既然winform跟SSMS的测试前提条件都不平等，何来一样的结果呢？？？

您好，ssms有问题的说法是SQL_Beginner这位大神说的。
msdn上的帖子也是我发的，两位大神是不是可以就在这个论坛讨论呢？
还有您的意思是 先进行一下操作
更新统计信息

USE [GPOSDB]
GO
UPDATE STATISTICS CT_FuelingData
UPDATE STATISTICS CT_InhouseCard
GO
清空缓冲

DBCC DROPCLEANBUFFERS
GO
DBCC FREEPROCCACHE
GO
ALTER INDEX REBUILD语句重建索引，保证没有索引碎片
在进行测试的结果就是比较准确的了吗？

#48

引用 47 楼 iammrwu 的回复:

Quote: 引用 43 楼 lyhab 的回复:

还有LZ说SSMS有问题，本人觉得不是SSMS的问题

因为winform跟SSMS统计的时间是不一样的

想知道LZ在winform里统计sql执行时间的代码是怎么写的

SSMS就只有set statistics time on，而C#是没有set statistics time on的

既然winform跟SSMS的测试前提条件都不平等，何来一样的结果呢？？？

您好，ssms有问题的说法是SQL_Beginner这位大神说的。
msdn上的帖子也是我发的，两位大神是不是可以就在这个论坛讨论呢？
还有您的意思是 先进行一下操作
更新统计信息

USE [GPOSDB]
GO
UPDATE STATISTICS CT_FuelingData
UPDATE STATISTICS CT_InhouseCard
GO
清空缓冲

DBCC DROPCLEANBUFFERS
GO
DBCC FREEPROCCACHE
GO
ALTER INDEX REBUILD语句重建索引，保证没有索引碎片
在进行测试的结果就是比较准确的了吗？

我不会再讨论，数据摆在那里，我觉得没有什么可争议的

#49

引用 46 楼 SQL_Beginner 的回复:

Quote: 引用 43 楼 lyhab 的回复:

还有LZ说SSMS有问题，本人觉得不是SSMS的问题

因为winform跟SSMS统计的时间是不一样的

想知道LZ在winform里统计sql执行时间的代码是怎么写的

SSMS就只有set statistics time on，而C#是没有set statistics time on的

既然winform跟SSMS的测试前提条件都不平等，何来一样的结果呢？？？

官网上一家给你回复了。

其实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里的时间在同一数量级了

#50

好吧，你很执着，所以再回答一下吧，
其实你的上面实验再次证明了是UI显示的问题，换句话说，如果是用SSMS的时候，是SSMS那个UI在显示的时候由于某个因素导致在服务器上那个SSMS在显示表格的时候比你在本地的慢，这个有很多因素的，我听说过某个显示器或者它的分别率都能影响SSMS打印那个数据表格的速度。

我说了，这个问题其实对你性能优化，监控什么的，影响不大，
当然如果你确实对那个问题很敢兴趣， 你跟微软CSS联系一下，让他们给你做个case，debugging一下，ETW tracking一下，看看时间花在SSMS里面的哪个函数上面，OKAY?