SQLServer 2000 進級到 SQLServer 2008 機能之須要留意的處所之一。本站提示廣大學習愛好者：（SQLServer 2000 進級到 SQLServer 2008 機能之須要留意的處所之一）文章只能為提供參考，不一定能成為您想要的結果。以下是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](
[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 呢？單單優化 索引 曾經處理不了基本成績了。
