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

來源:互聯網
上載者:User
測試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 呢?單單最佳化 索引 已經解決不了根本問題了。
相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.