none
SQL Server 2008 查询时间问题 RRS feed

  • 常规讨论

  • 我有一张表,共有56个字段。发现以下情况:
    1、我在我的开发机执行sql语句
    set statistics time on
    SELECT * FROM [eShop].[dbo].[Product]
    (多次执行,时间平均在90-100ms)
    2、在服务器上有相同的数据库,相同的表,相同的内容。执行同样SQL语句,执行结果为:
    (多次执行,时间平均在250ms)
    3、在我的开发机连服务器的数据库,执行该语句,执行结果为:
    (多次执行,平均时间只有35ms左右)
    以上是现象。
    问题是:同样的数据库,同样的表,同样的内容,同样的系统(server 2003),服务器的硬件也并不比我的开发机差,不知道为什么执行时间差这么多?
    而在硬件比较差的另一台服务器上用sqlserver2000的数据库查询速度反而更快。不知道是什么原因?有人碰到过吗?

    数据库版本为sqlserver 2008 R2 ,补丁为sp2。
    已经在多台服务器上做过测试,执行时间从七八十毫秒到五六百毫秒不等(有的硬件好的服务器执行时间反而比差的耗时还要长)。
    而且就取一百多条数据,怎么会用时这么长呢?sqlserver2005和sqlserver2008 似乎同样有这个问题。而在sqlserver2000上就没有这个问题(不会超过50ms)。
    2013年9月2日 9:09

全部回复

  • Did you check cpu and memory usage on sql server when doing those tests?
    2013年9月2日 15:36
  • 除了楼上说的部分,查一下是否有Blocking之类的?另外WaitType看看是什么?

    Please Mark As Answer if it is helpful.

    2013年9月3日 1:50
  • 这里我发不上来图

    您可以到

    http://q.cnblogs.com/q/54296/#c_556342

    http://bbs.csdn.net/topics/390577449?page=1#post-395468358

    这里看看么

    2013年9月3日 5:10
  • 看了LZ的提问,LZ的表是有聚集索引的,首先LZ的测试条件要平等

    更新统计信息

    USE [GPOSDB]
    GO
    UPDATE STATISTICS CT_FuelingData
    UPDATE STATISTICS CT_InhouseCard
    GO

    清空缓冲

    DBCC DROPCLEANBUFFERS
    GO
    DBCC FREEPROCCACHE
    GO

    ALTER INDEX REBUILD语句重建索引,保证没有索引碎片


    2013年9月9日 6:45
  • 这里我发不上来图

    您可以到

    http://q.cnblogs.com/q/54296/#c_556342

    http://bbs.csdn.net/topics/390577449?page=1#post-395468358

    这里看看么

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

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

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

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

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

     

    2013年9月9日 7:06
  • 这里我发不上来图

    您可以到

    http://q.cnblogs.com/q/54296/#c_556342

    http://bbs.csdn.net/topics/390577449?page=1#post-395468358

    这里看看么

    还有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?

    2013年9月9日 8:45
  • 这里我发不上来图

    您可以到

    http://q.cnblogs.com/q/54296/#c_556342

    http://bbs.csdn.net/topics/390577449?page=1#post-395468358

    这里看看么

    还有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?

    你说的是这篇文章吧

    SQL Server 性能调优 Wait Event

    关键是LZ有没有用XEVENT来捕获问题

    2013年9月10日 4:03
  • “关键是LZ有没有用XEVENT来捕获问题”

    你似乎没有认真看那个帖子嘛,你回头再看看呢

    2013年9月10日 5:18
  • 你应该是SQL_Beginner大侠吧

    csdn帖子我看了,争论也没有意义了

    而且LZ已经用XE检测出来了

    “而XE的结果很明显显示了:时间是用在了network_io上(223MS),由于SSMS在本地,那就不是网络传输问题了,而是SSMS本身的显示问题了”

    XE应该是任何版本的sql都可以检测出来的吧,包括:sql2000,sql2005

    2013年9月10日 5:50
  • 扩展事件是SQL 2008的新功能。

    想不想时已是想,不如不想都不想。

    2013年9月11日 18:17
    版主