SQLServer 2000 升级到 SQLServer 2008 性能之需要注意的地方之一_MsSql

测试sql:

复制代码 代码如下:

SET STATISTICS IO ON
SET STATISTICS TIME ON
SELECT COUNT(1)
FROM dbo.tbtext a
INNER LOOP JOIN dbo.tbtext b
ON a.id = b.id option (maxdop 1)
SET STATISTICS IO Off
SET STATISTICS TIME Off

表结构:

复制代码 代码如下:

CREATE TABLE [dbo].[tbtext](
[id] [int] IDENTITY(1,1) NOT NULL,
[VALUE] [int] NULL
) ON [PRIMARY]

单这句测试,看执行计划根本看不出区别。
|--Compute Scalar(DEFINE:([Expr1006]=CONVERT_IMPLICIT(int,[Expr1009],0)))
|--Stream Aggregate(DEFINE:([Expr1009]=Count(*)))
|--Nested Loops(Inner Join, WHERE:([northwind].[dbo].[tbtext].[id] as [b].[id]=[northwind].[dbo].[tbtext].[id] as [a].[id]))
|--Table Scan(OBJECT:([northwind].[dbo].[tbtext] AS [a]))
|--Table Spool
|--Table Scan(OBJECT:([northwind].[dbo].[tbtext] AS [b]))
2008r2:

复制代码 代码如下:

/*
警告: 由于使用了本地联接提示,联接次序得以强制实施。
表 'tbtext'。扫描计数 1,逻辑读取 46 次
(1 行受影响)
表 'Worktable'。扫描计数 1,逻辑读取 290098 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 'tbtext'。扫描计数 2,逻辑读取 262 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
(1 行受影响)
SQL Server 执行时间:
CPU 时间 = 32828 毫秒,占用时间 = 32846 毫秒。
SQL Server 执行时间:
CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。
*/

2000sp4:

复制代码 代码如下:

/*
警告: 由于使用了局部联接提示,所以联接次序得以强制实施。
表 'tbtext'。扫描计数 1,逻辑读 131 次,物理读 0 次,预读 0 次。
SQL Server 执行时间:
CPU 时间 = 0 毫秒,耗费时间 = 0 毫秒。
表 'Worktable'。扫描计数 9999,逻辑读 180001 次,物理读 0 次,预读 0 次。
表 'tbtext'。扫描计数 2,逻辑读 262 次,物理读 0 次,预读 138 次。
SQL Server 执行时间:
CPU 时间 = 17188 毫秒,耗费时间 = 17261 毫秒。
(1 行受影响)
SQL Server 执行时间:
CPU 时间 = 0 毫秒,耗费时间 = 0 毫秒。
*/

比较2000 和 2008的执行就能发现 2008 的cpu 时间明显比 2000 高,2008 的worktable 逻辑读取量,比2000的高,
这个有个worktable 的扫描技术,2000的是9999,2008的是1,这个让人难免有的疑惑是什么情况,都是nest loop,worktable 扫描不应该是1才对。
性能差怎么大会不会是 worktable 搞的鬼呢?
那么就开始调节,过滤id 会有啥发现呢?

复制代码 代码如下:

SET STATISTICS IO ON
SET STATISTICS TIME ON
SELECT COUNT(1)
FROM dbo.tbtext a
INNER LOOP JOIN dbo.tbtext b
ON a.id = b.id
WHERE a.id <= 1000 option (maxdop 1)
SELECT COUNT(1)
FROM dbo.tbtext a
SET STATISTICS IO Off
SET STATISTICS TIME Off

2008r2:
SELECT COUNT(1) FROM dbo.tbtext a INNER LOOP JOIN dbo.tbtext b ON a.id = b.id WHERE a.id <= 1000 option (maxdop 1)
|--Compute Scalar(DEFINE:([Expr1006]=CONVERT_IMPLICIT(int,[Expr1009],0)))
|--Stream Aggregate(DEFINE:([Expr1009]=Count(*)))
|--Nested Loops(Inner Join, WHERE:([northwind].[dbo].[tbtext].[id] as [b].[id]=[northwind].[dbo].[tbtext].[id] as [a].[id]))
|--Table Scan(OBJECT:([northwind].[dbo].[tbtext] AS [a]), WHERE:([northwind].[dbo].[tbtext].[id] as [a].[id]<=(1000)))
|--Table Spool
|--Table Scan(OBJECT:([northwind].[dbo].[tbtext] AS [b]), WHERE:([northwind].[dbo].[tbtext].[id] as [b].[id]<=(1000)))

复制代码 代码如下:

表 'Worktable'。扫描计数 1,逻辑读取 6006 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 'tbtext'。扫描计数 2,逻辑读取 262 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

2000sp4:
|--Compute Scalar(DEFINE:([Expr1002]=Convert([Expr1006])))
|--Stream Aggregate(DEFINE:([Expr1006]=Count(*)))
|--Nested Loops(Inner Join, WHERE:([b].[id]=[a].[id]))
|--Table Scan(OBJECT:([Northwind].[dbo].[tbtext] AS [a]), WHERE:([a].[id]<=1000))
|--Table Spool
|--Table Scan(OBJECT:([Northwind].[dbo].[tbtext] AS [b]))

复制代码 代码如下:

表 'Worktable'。扫描计数 999,逻辑读 27001 次,物理读 0 次,预读 0 次。
表 'tbtext'。扫描计数 2,逻辑读 262 次,物理读 0 次,预读 0次。

进入 lazy spool的数据完全不一样了,2008 只是进入了1000 条数据,但是2000 全都进去了。
在逻辑读上面 2008 明显低于 2000. cpu时间也明显比2000少。
通过调节id 的值,2000 我推出了一个公式 逻辑读= 10001+(17*n) ,
但是2008的算法十分奇怪,
当n < 386 时 逻辑读=3+4(n-1)
当 386<=n<=770 逻辑读= 1932+5(n-386)
2000的逻辑读是线性增长,2008 是分段的线性增长,每个分段 f '(x) 都不一样。
2008 的lazy spool适合选择度高的,选择度低的时候完全不行。
从2000到2008 不单单是多了sqlos和表面上的一些功能,很多执行计划的操作符都被重写了,像lazy spool 。
所以在升级到2008 之前,
各位朋友,是否都应该重写一下sql 呢?单单优化 索引 已经解决不了根本问题了。

时间: 2024-11-05 12:28:05

SQLServer 2000 升级到 SQLServer 2008 性能之需要注意的地方之一_MsSql的相关文章

SQLServer 2000 升级到 SQLServer 2008 性能之需要注意的地方之一

测试sql: 复制代码 代码如下: SET STATISTICS IO ON SET STATISTICS TIME ON SELECT COUNT(1) FROM dbo.tbtext a INNER LOOP JOIN dbo.tbtext b ON a.id = b.id option (maxdop 1) SET STATISTICS IO Off SET STATISTICS TIME Off 表结构: 复制代码 代码如下: CREATE TABLE [dbo].[tbtext]( [

怎样获得Sqlserver 2000得实例列表和运行在一个实例上得数据库列表

server|sqlserver|数据|数据库 在.Net FrameWork中,能够很方便调用COM组件,有些时候我们需要获得运行在某个Sql Server上得服务实例列表和在一个实例上得数据库列表,通过Microsoft.SQLDMO.Object组件就可以轻松完成此项工作:首先如何找到Microsoft.SQLDMO.Object1.如何在您得项目中能够使用SQLDMO组件?菜单-项目-添加引用-COM-Microsoft.SQLDMO.Object 2.将该功能写成一个类:   1usi

SQLServer 2000 中视图的一个 bug

server|sqlserver|视图 昨天(零点过了哟),在苏州中部电子有限公司生产受发注在库管理系统中遇到一个奇怪的问题.前些天我测试得好好的程序,昨天给测试人员测试后得出了莫名其妙的错误,今天bug报告拿来了,我就陷入了奇怪的圈套中,因为我们的项目中用了大量的视图,当然这个错误就出在视图上.就是在视图中的那个"*",哈哈. 测试环境:OS: Windows Server 2000/2003Microsoft SQLServer: 2000 简体中文企业版 测试步骤(演示):第一步

如何远程访问SQLSERVER 2000

问题描述 把网站部署在IIS访问一台电脑上的sqlserver2000,老是报链接不上数据库的错误.有遇到这个问题的吗 解决方案 解决方案二:1.先看数据库实例是否是默认实例,否则必须在连接字符串里写上实例名称2.数据库要设置允许远程连接解决方案三: 解决方案四:应该把SQLSERVER登录认证模式改为混合认证模式解决方案五:我在VS里调试没问题,在IIS就连不上,请问是什么原因解决方案六:肯定是混合验证了,而且远程通过数据库是可以连上的解决方案七:请大神帮忙啊,小弟第一次问问题解决方案八:设置

SQL Server 2008性能故障排查(三)——I/O

原文:SQL Server 2008性能故障排查(三)--I/O 接着上一章:CPU瓶颈 I/O瓶颈(I/O Bottlenecks): SQLServer的性能严重依赖I/O子系统.除非你的数据库完全加载到物理内存中,否则SQLServer会不断地把数据库文件从缓存池中搬进搬出,这会引起大量的I/O传输.同样地,日志记录在事务被声明为已提交前必须写入磁盘.最后,SQLServer基于许多原因使用tempdb,比如存储临时结果.排序和保持行版本.所以一个好的I/O子系统是SQLServer性能关

SQL Server 2008性能故障排查(二)——CPU

原文:SQL Server 2008性能故障排查(二)--CPU 承接上一篇:SQL Server 2008性能故障排查(一)--概论 说明一下,CSDN的博客编辑非常不人性化,我在word里面都排好了版,贴上来就乱得不成样了.建议CSDN改进这部分.也请大家关注内容不要关注排版.同时在翻译的过程中本人也整理了一次思路,所以还似乎非常愿意翻译,虽然有点自娱自乐,但是分享给大家也是件好事 CPU 瓶颈:CPU瓶颈可能因为某个负载所需的硬件资源不足而引起.但是过多的CPU使用通常可以通过查询优化(特

SQL 2000怎么向SQL 2008 R2推送数据?

  最近做的一个项目要获取存在于其他服务器的一些数据,为了安全起见,采用由其他"服务器"向我们服务器推送的方式实现.我们服务器使用的是sql server 2008 R2,其他"服务器"使用的都是SQL Server 2000,还都是运行在Windows XP上的,整个过程遇到了一些问题,也参考了一些文档,最终费了好多事才算搞定. [一.配置分发服务器] SQLServer 2000的复制服务包括三个角色:发布服务器.分发服务器和订阅服务器,关系如图1所示. 图1

SQL Server 2008性能故障排查(一)——概论

原文:SQL Server 2008性能故障排查(一)--概论 备注:本人花了大量下班时间翻译,绝无抄袭,允许转载,但请注明出处.由于篇幅长,无法一篇博文全部说完,同时也没那么快全部翻译完,所以按章节发布.由于本人水平有限,翻译结果肯定存在问题,为了不造成误导,在每篇结尾处都附上原文,供大家参考,也希望能指出我的问题,以便改进.谢谢. 另外,本文写给稍微有经验的数据库开发人员或者DBA看,初学者可能会看不懂.在此请见谅 作者:Sunil Agarwal, Boris Baryshnikov, K

SQL Server 2008性能故障排查(四)——TempDB

原文:SQL Server 2008性能故障排查(四)--TempDB 接着上一章:I/O TempDB:          TempDB是一个全局数据库,存储内部和用户对象还有零食表.对象.在SQLServer操作过程中产生的存储过程等数据.在一个SQLServer实例中,只有一个TempDB.所以容易成为性能和磁盘空间瓶颈.TempDB可能因为空间可用程度和过量的DDL和DML操作而变得超负荷.这可能导致不相关的应用运行缓慢甚至失败.          常见的TempDB问题如下: l  T