淺析SQL Server的嵌套存儲過程中使用同名的臨時表怪像

Posted on by

SQL Server的嵌套存儲過程，外層存儲過程和內層存儲過程（被嵌套調用的存儲過程）中可以存在相同名稱的本地臨時表嗎？如果可以的話，那麼有沒有什麼問題或限制呢？ 在嵌套存儲過程中，調用的是外層存儲過程的臨時表還是自己定義的臨時表呢？ 是否類似高級語言的變量一樣，本地臨時表有沒有“作用域“范圍呢？

註意：也可以稱呼為父存儲過程和子存儲過程，外層存儲過程和內層存儲過程。這些隻是不同的稱呼或叫法而已。我們這裡統一使用外層存儲過程和內層存儲過程。後續文章部分不再述說。

我們先來看一個例子，如下所示，我們構造一個簡單的例子。

IF EXISTS (SELECT 1 FROM sys.objects WHERE object_id = OBJECT_ID(N'dbo.PRC_TEST') AND OBJECTPROPERTY(object_id, 'IsProcedure') =1)
BEGIN
  DROP PROCEDURE dbo.PRC_TEST
END
GO
CREATE PROC dbo.PRC_TEST
AS
BEGIN
 
  CREATE TABLE #tmp_test(id INT);
 
  INSERT INTO #tmp_test
  SELECT 1;
 
  SELECT * FROM #tmp_test;
 
  EXEC PRC_SUB_TEST
 
  SELECT * FROM #tmp_test
  
 
END
GO
 
IF EXISTS(SELECT 1 FROM sys.objects WHERE object_id= OBJECT_ID(N'dbo.PRC_SUB_TEST' ) AND OBJECTPROPERTY(object_id, 'IsProcedure')=1)
BEGIN
  DROP PROCEDURE dbo.PRC_SUB_TEST;
END
GO
 
CREATE PROCEDURE dbo.PRC_SUB_TEST
AS
BEGIN
  
  CREATE TABLE #tmp_test(name VARCHAR(128));
 
  INSERT INTO #tmp_test
  SELECT name FROM sys.objects
 
  SELECT * FROM #tmp_test;
END
GO
 
EXEC PRC_TEST;

簡單測試似乎正常，並沒有發現什麼問題。如果此時你就下一個結論的話，那麼就為時過早瞭！ 打個比方，你看見一隻天鵝是白色的，如果你下瞭一個定論：“所有天鵝都是白色的”，其實這個世界真的有黑天鵝，隻是你沒有見過而已！如下所示，我們修改一下存儲過程dbo.PRC_SUB_TEST，使用字段名name替換*，如下所示：

IF EXISTS(SELECT 1 FROM sys.objects WHERE object_id= OBJECT_ID(N'dbo.PRC_SUB_TEST' ) AND OBJECTPROPERTY(object_id, 'IsProcedure')=1)
BEGIN
  DROP PROCEDURE dbo.PRC_SUB_TEST;
END
GO
 
CREATE PROCEDURE dbo.PRC_SUB_TEST
AS
BEGIN
  
  CREATE TABLE #tmp_test(name VARCHAR(128));
 
  INSERT INTO #tmp_test
  SELECT name FROM sys.objects
 
  SELECT name FROM #tmp_test;
END
GO

然後重復上面測試，如下所示，此時執行存儲過程dbo.PRC_TEST的話，就會報錯：“Invalid column name ‘name’.”

此時隻要先我執行一次存儲過程dbo.PRC_SUB_TEST，然後再去執行存儲過程dbo.PRC_TEST就不會報錯瞭。而且隻要執行過一次這個存儲過程，然後在當前會話或其它任何會話執行dbo.PRC_TEST都不會報錯瞭。是否非常讓人迷惑或不解。

EXEC dbo.PRC_SUB_TEST;
 
EXEC PRC_TEST;

如果你要再次重現這個現象的話，隻能通過下面SQL或者刪除/重建存儲過程的方式，才能重現這個現象。似乎有點幽靈現象的感覺。

DBCC FREEPROCCACHE

關於這個現象，官方文檔（詳見參考資料的鏈接地址）有這麼一段描述：

A local temporary table created within a stored procedure or trigger can have the same name as a temporary table that was created before the stored procedure or trigger is called. However, if a query references a temporary table and two temporary tables with the same name exist at that time, it is not defined which table the query is resolved against. Nested stored procedures can also create temporary tables with the same name as a temporary table that was created by the stored procedure that called it. However, for modifications to resolve to the table that was created in the nested procedure, the table must have the same structure, with the same column names, as the table created in the calling procedure. This is shown in the following example.

在存儲過程或觸發器中創建的本地臨時表的名稱可以與在調用存儲過程或觸發器之前創建的臨時表名稱相同。 但是，如果查詢引用臨時表，而同時有兩個同名的臨時表，則不定義針對哪個表解析該查詢。 嵌套存儲過程同樣可以創建與調用它的存儲過程所創建的臨時表同名的臨時表。但是，為瞭對其進行修改以解析為在嵌套過程中創建的表，此表必須與調用過程創建的表具有相同的結構和列名。下面的示例說明瞭這一點。

CREATE PROCEDURE dbo.Test2
AS
  CREATE TABLE #t(x INT PRIMARY KEY);
  INSERT INTO #t VALUES (2);
  SELECT Test2Col = x FROM #t;
GO
 
CREATE PROCEDURE dbo.Test1
AS
  CREATE TABLE #t(x INT PRIMARY KEY);
  INSERT INTO #t VALUES (1);
  SELECT Test1Col = x FROM #t;
EXEC Test2;
GO
 
CREATE TABLE #t(x INT PRIMARY KEY);
INSERT INTO #t VALUES (99);
GO
 
EXEC Test1;
GO

官方文檔中“同時有兩個同名的臨時表，則不定義針對哪個表解析該查詢”這種闡述感覺還是讓人有點迷糊。這裡簡單解釋一下，在存儲過程的嵌套調用中，允許外層過程和內層存儲過程中存在相同名字的本地臨時表，但是在內存過程中，如果要對其進行修改或解析（修改很好理解，例如新增索引，增加字段等這類DDL操作；關於解析，查詢臨時表，SQL中指定字段名，就需要解析resolve），那麼此時這個臨時表必須表結構一致，否則就會報錯。官方文檔，就是這麼一句話，告訴你不行，但是具體原因沒有說。那麼我們不妨做一些推測，在存儲過程的嵌套調用中，是否創建瞭兩個本地臨時表呢？有沒有可能實際隻創建瞭一個本地臨時表呢？出現本地臨時表重用的情況呢？ 那麼我們簡單驗證一下，如下所示，這裡可以判斷實際上創建瞭兩個本地臨時表。並沒有出現臨時表重用的情況。

SELECT * 
FROM sys.dm_os_performance_counters
WHERE counter_name LIKE 'Temp Tables Creation Rate%';
 
EXEC PRC_TEST;
 
SELECT * 
FROM sys.dm_os_performance_counters
WHERE counter_name LIKE 'Temp Tables Creation Rate%';

當然你可以用下面SQL來進行驗證，跟上面驗證的結果一致。

IF EXISTS(SELECT 1 FROM sys.objects WHERE object_id= OBJECT_ID(N'dbo.PRC_SUB_TEST' ) AND OBJECTPROPERTY(object_id, 'IsProcedure')=1)
BEGIN
  DROP PROCEDURE dbo.PRC_SUB_TEST;
END
GO
 
 
CREATE PROCEDURE dbo.PRC_SUB_TEST
AS
BEGIN
  
  SELECT * FROM #tmp_test;
 
  SELECT * FROM tempdb.dbo.sysobjects WHERE name LIKE '#tmp_test%'
  CREATE TABLE #tmp_test(name VARCHAR(128));
 
  INSERT INTO #tmp_test
  SELECT name FROM sys.objects
  SELECT * FROM tempdb.dbo.sysobjects WHERE name LIKE '#tmp_test%'
  SELECT * FROM #tmp_test;
END
GO

然後我們來看看臨時表的“作用域”，抱歉我用這麼一個概念，官方文檔是沒有這個概念，這個隻是我們思考的一個方面，細節方面沒有必要抬杠。如下所示，我們修改一下存儲過程

IF EXISTS(SELECT 1 FROM sys.objects WHERE object_id= OBJECT_ID(N'dbo.PRC_SUB_TEST' ) AND OBJECTPROPERTY(object_id, 'IsProcedure')=1)
BEGIN
  DROP PROCEDURE dbo.PRC_SUB_TEST;
END
GO
CREATE PROCEDURE dbo.PRC_SUB_TEST
AS
BEGIN
  
  SELECT * FROM #tmp_test;
  CREATE TABLE #tmp_test(name VARCHAR(128));
 
  INSERT INTO #tmp_test
  SELECT name FROM sys.objects
 
  SELECT * FROM #tmp_test;
END
GO

通過實驗驗證，我們發現外層存儲過程的臨時表在內層存儲過程中有效，它的“作用域”是在內層存儲過程的同名臨時表創建之前，這個跟高級語言中的全局變量和局部變量作用域有點類似。

既然創建瞭兩個本地臨時表，那麼為什麼修改或解析的時候就會報錯呢？ 個人的一個猜測是，優化器解析過後，在執行過程中，解析或修改的時候，數據庫引擎無法判斷或者代碼裡面沒有這種邏輯去控制檢索哪一個臨時表。有可能是代碼裡面的一個缺陷亦或是某種邏輯原因導致。上述僅僅是個人的一個猜測、推理。如有不足或不對的地方，敬請指正。

參考資料：

https://docs.microsoft.com/zh-cn/previous-versions/sql/sql-server-2012/ms174979(v=sql.110)?redirectedfrom=MSDN

到此這篇關於淺析SQL Server的嵌套存儲過程中使用同名的臨時表怪像的文章就介紹到這瞭,更多相關SQL Server嵌套存儲過程內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：