DDR爱好者之家 Design By 杰米
测试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 呢?单单优化 索引 已经解决不了根本问题了。
复制代码 代码如下:
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 呢?单单优化 索引 已经解决不了根本问题了。
DDR爱好者之家 Design By 杰米
广告合作:本站广告合作请联系QQ:858582 申请时备注:广告合作(否则不回)
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
DDR爱好者之家 Design By 杰米
暂无评论...
RTX 5090要首发 性能要翻倍!三星展示GDDR7显存
三星在GTC上展示了专为下一代游戏GPU设计的GDDR7内存。
首次推出的GDDR7内存模块密度为16GB,每个模块容量为2GB。其速度预设为32 Gbps(PAM3),但也可以降至28 Gbps,以提高产量和初始阶段的整体性能和成本效益。
据三星表示,GDDR7内存的能效将提高20%,同时工作电压仅为1.1V,低于标准的1.2V。通过采用更新的封装材料和优化的电路设计,使得在高速运行时的发热量降低,GDDR7的热阻比GDDR6降低了70%。
更新日志
2024年11月23日
2024年11月23日
- 凤飞飞《我们的主题曲》飞跃制作[正版原抓WAV+CUE]
- 刘嘉亮《亮情歌2》[WAV+CUE][1G]
- 红馆40·谭咏麟《歌者恋歌浓情30年演唱会》3CD[低速原抓WAV+CUE][1.8G]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[320K/MP3][193.25MB]
- 【轻音乐】曼托凡尼乐团《精选辑》2CD.1998[FLAC+CUE整轨]
- 邝美云《心中有爱》1989年香港DMIJP版1MTO东芝首版[WAV+CUE]
- 群星《情叹-发烧女声DSD》天籁女声发烧碟[WAV+CUE]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[FLAC/分轨][748.03MB]
- 理想混蛋《Origin Sessions》[320K/MP3][37.47MB]
- 公馆青少年《我其实一点都不酷》[320K/MP3][78.78MB]
- 群星《情叹-发烧男声DSD》最值得珍藏的完美男声[WAV+CUE]
- 群星《国韵飘香·贵妃醉酒HQCD黑胶王》2CD[WAV]
- 卫兰《DAUGHTER》【低速原抓WAV+CUE】
- 公馆青少年《我其实一点都不酷》[FLAC/分轨][398.22MB]
- ZWEI《迟暮的花 (Explicit)》[320K/MP3][57.16MB]