SQL SERVER修改函數名容易引發的問題分析

這篇文章主要介紹了SQL SERVER修改函數名容易引發的問題分析的相關資料,需要的朋友可以參考下

1. 問題

今天遇到一個奇怪的問題：使用sp_helptext XXX查詢出來的函數定義名竟然跟函數名不同，而sp_helptext實際是查詢sys.all_sql_modules這個系統視圖的。直接查詢這個視圖的definition字段，發現跟sp_helptext是一樣的。難道是系統視圖也存在緩存之類的機制？或者是個BUG？對於第一個問題，當時情況緊急，沒有時間去求證是否存在了。第二個問題，我想沒什麼可能，SQL SERVER發展到今天（SQL 2016正式版准備推出，我使用的環境則是SQL 2008 R2，打了SP3），已經是很成熟的一個系統，即使是出現BUG也不是我這種水平的人能發現的，肯定是哪我哪裡弄錯了。於是求助於數據庫技術交流群，很快有大神回答了是改名的問題。我馬上就想起這個函數在一個多星期前，因為測試的需要，通過SSMS改了原函數名，而SQL SERVER不會因為改名去更新sys.all_sql_modules視圖的definition字段的！於是就造成了已經編譯好的函數與sys.all_sql_modules系統視圖的函數定義出現了不一致的情況。

2. 重視與分析問題

做一個測試來重現下問題。首先，新建一個簡單的測試函數dbo.ufn_test_1。

USE AdventureWorks2008R2;
GO
IF OBJECT_ID(N'dbo.ufn_test_1') IS NOT NULL
BEGIN
DROP FUNCTION dbo.ufn_test_1;
END
GO
CREATE FUNCTION dbo.ufn_test_1 ()
RETURNS CHAR(1)
AS
BEGIN
RETURN ('F');
END
GO 

code-1: 創建函數dbo.ufn_test_1

這時，使用sp_helptext和sys.all_sql_modules查詢，一切正常。

EXEC sp_helptext [dbo.ufn_test_1];
GO
SELECT OBJECT_ID('dbo.ufn_test_1') AS a, * 
FROM sys.all_sql_modules
WHERE [object_id] = OBJECT_ID('dbo.ufn_test_1');
GO 

code-2:查詢函數dbo.ufn_test_1的定義

figure-1: 查詢函數dbo.ufn_test_1的定義

在SSMS上直接改名為dbo.ufn_test_2。

figure-2: 修改函數名

再去查詢函數dbo.ufn_test_2的定義。這樣，就出現了已經編譯好的函數跟在視圖中的函數定義出現了不一致的情況！如果通過sp_helptext和sys.all_sql_modules查詢出現的定義去更新生產服務器，就肯定會出現問題。

3. 解決與結論

解決方法也很簡單，把這個函數重建即可。如果使用SSMS的右鍵修改（Modify）或生成相關腳本（Script Function as）的菜單，則不會出現以上的問題。同樣的問題與解決方法，也適用於存儲過程。

結論：

（1）盡量不要修改對象名，確實要修改的話，就重建吧。如果是表並且包含的大量數據要重建的話，就比較麻煩了，即使是修改表名不會出現像函數、存儲過程的問題，但修改表名涉及應用程序等問題。

（2）盡量使用SSMS的右鍵菜單修改或生成對象的定義。但如果函數或存儲過程太多，會覺得sp_helptext和sys.all_sql_modules會更方便些，查詢出來的結果要認真核對下對象名是否一致即可。這裡提一下，sp_helptext有些限制，可以參考SQL中print、sp_helptext的限制與擴展。