曾經在網路上看到過，SqlServer的儲存過程中使用臨時表，會導致執行計劃無法重用，

執行時候會導致重編譯的這麼一個說法，自己私底下去做測試的時候，根據profile的跟蹤結果，

如果不是統計資訊變更導致導致的重編譯，單單是使用臨時表，並不會導致重編譯，

但是對於一些特殊的情況，又確實會出現重編譯的，

為了弄清楚這個問題，查閱了大量的資料，才把這個問題弄清楚，這裡特意記錄下來，希望武斷地認為儲存過程中使用了臨時表就會導致重編譯的這個觀點得到糾正。

首先進行下面的測試，我們知道，導致臨時表重編譯的因素之一就是統計資訊的變化，統計資訊的變化依賴於往臨時表中寫入的資料量，

首選我要控制插入臨時表中的資料量不超過統計資訊更新而導致重編譯的閥值，先排除統計資訊的變更導致重編譯，

看看僅僅是多次執行SP，是否因為儲存過程中有了臨時表而會產生重編譯

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

--首選建立一個表，供儲存過程中測試使用 create table test1 ( id int identity(1,1), name varchar(50) ) --插入10000條測試資料 insert into test1 values (NEWID()) go 10000 --建立一個儲存過程，其中儲存過程中定義了一個臨時表，根據引數，往臨時表中寫入資料 create proc testRecompile(@i  int) as begin create table #t (id int,name varchar(50)) insert into #t select id,name from test1 where id<@i select * from #t end

那麼就開始執行這個SP，然後監控profile，看看第一次執行，以及除了第一次執行之後，到底有沒有發生重編譯

1 2 3 4

--第一次執行，代入引數1 exec testRecompile 1 --第二次執行，代入引數2 exec testRecompile 2

下面是profile的截圖，可以很清楚地看到，第一次執行之後，再次執行SP的時候，沒有發生重編譯的動作，也就是說重用了第一次的執行計劃快取

這裡解釋兩個問題，

1，第一次執行的時候，為什麼不是因為架構更改導致的重編譯，而是Deferred Complie？

2，第二次執行的時候，為什麼沒有重編譯，因為臨時表是每次執行的時候建立的啊，肯定是更改了架構（change schema）了，為什麼沒有重編譯？

首先，說明第一個問題，

1，第一次執行的時候，當儲存過程testRecompile編譯的時候，

　　插入語句（insert into #t select id,name from test1 where id<@i）和查詢語句（select * from #t），

　　因為#t表還沒有被建立，因為這兩句並沒有被編譯，

　　編譯的時候的執行計劃並沒有完全完成，

　　當這個儲存過程執行的時候，臨時表才被建立，此時才真正的開始編譯臨時表物件的語句，這個編譯的過程是執行的時候完成的，而不是純粹的編譯階段完成的

　　所以這是Deferred Complie，也即是執行時才進行的編譯，就是所謂的延遲編譯（Deferred Complie）。

2，第二個問題，重新執行臨時表的時候，按道理，因為建立了臨時表，必然導致架構的更改，為什麼沒有重編譯？

　　這個是因為，儲存過程中使用了臨時表，對臨時表的使用是引用其“名稱”（比如這裡的#t），而非ID（從臨時資料庫中查詢sys.sysobjects）

　　雖然多個會話同時執行這個SP的話，每個會話都會生成一個臨時表，每個會話生成的臨時表的ID都是不同的，

　　但是要注意的是，儲存過程中並沒有直接使用臨時表物件的ID，而是臨時表名字本身，

　　第一次執行之後，快取的執行計劃與第二次執行時一樣的，所以第二次執行這個SP可以重用這個第一次生成的執行計劃，

上面說了，在某些情況下，儲存過程中使用臨時表會導致重編譯，這是在什麼情況下發生的呢？

因為在某些情況下，要先生成臨時表，然後以動態sql的方式去執行一段有臨時表參與的sql，此時對於臨時表的引用是引用其ID，而不是名稱

這個要歸結於對於臨時表的呼叫方式，當儲存過程中定義了臨時表，用exec或者是sp_executesql的方式呼叫的時候，這兩種執行sql的方式相當於新建了會話，

此時因為不同回話之間，同一個臨時表生成的ID是不同的，此時才會導致儲存過程中發生sechme change的重編譯

上程式碼

1 2 3 4 5 6 7 8 9 10 11 12 13

create proc testRecompile2(@i int) as begin create table #t (id int,name varchar(50)) insert into #t select id,name from test1 where id<[email protected] exec('select * from #t') end DBCC FREEPROCCACHE --第一次執行，代入引數1 exec testRecompile2 1 --第二次執行，代入引數2 exec testRecompile2 2

在儲存過程中建立了臨時表，以exec或者sp_executesql的方式執行臨時表的sql的時候，才會發生因為schema change導致的重編譯，

因為這兩種方式執行sql，相當於新建會話去執行sql，此時對於臨時表的引用，是引用臨時表生成的ID，不同會話之間的臨時表物件的ID是不同的，所以無法重用執行計劃，會發生重編譯

相關推薦