首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 数据库 > SQL Server >

SQL Server 2008 r2 查询效率有关问题

2013-09-12 
SQL Server 2008 r2 查询效率问题我有一张表,共有56个字段。发现以下情况:1、我在我的开发机执行sql语句set

SQL Server 2008 r2 查询效率问题
我有一张表,共有56个字段。发现以下情况:
1、我在我的开发机执行sql语句
set statistics time on
SELECT * FROM [eShop].[dbo].[Product]
SQL Server 2008 r2 查询效率有关问题
(多次执行,时间平均在90-100ms)
2、在服务器上有相同的数据库,相同的表,相同的内容。执行同样SQL语句,执行结果为:
SQL Server 2008 r2 查询效率有关问题
(多次执行,时间平均在250ms)
3、在我的开发机连服务器的数据库,执行该语句,执行结果为:
SQL Server 2008 r2 查询效率有关问题
(多次执行,平均时间只有35ms左右)
以上是现象。
问题是:同样的数据库,同样的表,同样的内容,同样的系统(server 2003),服务器的硬件也并不比我的开发机差,不知道为什么执行时间差这么多?
而在硬件比较差的另一台服务器上用sqlserver2000的数据库查询速度反而更快。不知道是什么原因?有人碰到过吗?
///*************/////
我的开发机profile中
SQL Server 2008 r2 查询效率有关问题
服务器上profile中
SQL Server 2008 r2 查询效率有关问题
///*************/////
数据库版本为sqlserver 2008 R2 ,补丁为sp2。
已经在多台服务器上做过测试,执行时间从七八十毫秒到五六百毫秒不等(有的硬件好的服务器执行时间反而比差的耗时还要长)。
而且就取一百多条数据,怎么会用时这么长呢?sqlserver2005和sqlserver2008 似乎同样有这个问题。而在sqlserver2000上就没有这个问题(不会超过50ms)。 数据库 sql?server?2008?r2 服务器 查询效率
[解决办法]
先看下各个机器上的实际执行计划。有什么不同吗?
[解决办法]

引用:
开发机
服务器

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

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

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

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

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

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 试试
[解决办法]

引用:
引用
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())


[解决办法]
如果你觉得那个几百毫秒的语句有问题,那你按下面帖子中103楼的做法,把结果贴出来,看看时间到底花在哪里?
http://bbs.csdn.net/topics/390505826?page=2
[解决办法]
开发机和服务器的负载不一样,数据量不一样,索引碎片程度不一样,数据缓存情况不一样

看你贴的索引碎片不少,先整理下索引碎片吧
DBCC DBREINDEX ''
[解决办法]
试试用13楼的办法,其实就是能明确区分这些时间:

PAGEIOLATCH_SH
PREEMPTIVE_OS_WAITFORSINGLEOBJECT
NETWORK_IO
SOS_SCHEDULER_YIELD

这样你就知道,到底多出来的时间,用在哪儿了
[解决办法]
1.所有的IO都是逻辑读,没有物理读,说明数据都被缓存在内存中了
2.根据执行计划,聚集索引扫描的开销最大,因此结合1,说明时间主要消耗在扫描索引上,那么通过重建索引减少索引页数,应该是最佳的调优策略
[解决办法]
引用:
Quote: 引用:

Quote: 引用:

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



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


SQL Server 2008 r2 查询效率有关问题
SQL Server 2008 r2 查询效率有关问题

是这样吧?

GOOD,
大部分时间用在NETWORK_IO上,很明显是网络的问题。
[解决办法]
呵呵,网络问题,真是出乎意料之外,之前我也碰到一次这种问题,百思不得其解,

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

而查询11条就瞬间提升到80ms
SQL Server 2008 r2 查询效率有关问题
这个又是怎么回事?

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

以后再点就在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等)。
[解决办法]
还有LZ说SSMS有问题,本人觉得不是SSMS的问题

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

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

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

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

热点排行