為什么不要讓 SQLServer 幫你自動轉換 SQL 命令中的數據類型

Report Date ： ?? 2003/12/5	Prepared by ： ???? 鄭 昀
Article last modified on 2004-2-16
The information in this article applies to: ü ???????? Microsoft SQL Server 2000,7.0

問題陳述 :

有一天，執行

SELECT * FROM XXX_ORIGINAL_20031205
where msgid =62010388000012

語句，結果 SQL Server 報告出錯： “ 將數據類型 varchar 轉換為 numeric 時出錯。 ”

?

這是什么意思呢？

Msgid 這個字段的類型是： varchar(30) 。

?

環境：

數據庫服務器： Microsoft SQL Server 2000 以及 7.0 ；

數據庫服務器補丁： Microsoft SQL Server 2000 ServicePack1 ；

?

原因分析：

不是 SQL Server 突然不能從數字自動轉換為字符串，而是單單對這個字段的數值有問題，這也和這個字段中實際已存儲的字符串有關。

?

你看，我執行這個 SQL 語句是沒有問題，可以自動轉換：

SELECT * FROM XXXX_ORIGINAL_20031205
where recordid =62010388000012

recordid 這個字段的類型也是： varchar(30) 。

這為什么就可以呢？

?

為什么？

這是因為 msgid 字段的真實數值是類似于這樣的字符串 “12051113280101053509” ，由于你的 SQL 命令中要求拿字符串跟我們提供的這個數字 62010388000012 匹配，所以 SQLServer 默認要把這么多個 “12051113280101053509” 先統統轉換為數字，再去跟 62010388000012 匹配。

( 首先這就涉及到一個效率問題，轉換這么多 msgid 成為數字，再跟你的數字匹配，將是一個多么大的浪費啊 )

當然，這回 SQLServer 轉不過來了，因為 “12051113280101053509” 換為數字實在太大了，超出了范圍，所以你看 SQLServer 于是乎報告 “ 將數據類型 varchar 轉換為 numeric 時出錯 ” ，他指的就是把歷史數據 “12051113280101053509” 這個 varchar(30) 轉成 numeric 不行，而不是把你 SQL 腳本傳遞的參數 62010388000012 轉換失敗。

?

讓我們看看另一種形式的錯誤，就更清楚了：

我們執行

SELECT * FROM XXXX_ORIGINAL_20031205
where msgid=120

命令就會得到錯誤：

varchar 值 '12050003010101026986' 的轉換溢出了 int 列。超出了最大整數值。

?

這個錯誤，是不是很清楚地表明了 SQLServer 在幫你執行 SQL 命令時背后所作的事情？

他試圖幫你主動把記錄中的這個字段轉換成你在 SQL 命令中指明的那個數據類型。

?

我的建議：

很多時候，我們懶得去看某個字段到底是什么類型，是 char ，還是 tinyint ，還是 bool ，還是 varchar ，我們就隨便寫一個數字，讓聰明的 SQL Server 自己去判斷該轉成什么。

但是，第一， SQL Server 不是轉換你的腳本命令中的數值，而是轉換已有的歷史數據到你指定的那個類型，所以會增加執行時間；第二，容易轉換出錯。

所以，切忌讓 SQLServer 自己判斷，自動幫你轉換，那樣將降低執行效率，而且增加出錯幾率。你能夠顯式告訴 SQL Server 你的數據類型的話，就請一定這么做。

?

?

Writen by zhengyun.NoJunk(at)tomosoft.dot.com

Disclaimers ：

本文檔所包含的信息代表了在發布之日， ZhengYun 對所討論問題的當前看法， Zhengyun 不保證所給信息在發布之日以后的準確性。

本文檔僅供參考。對本文檔中的信息， Zhengyun 不做任何明示或默示的保證。

用戶必須遵守所有適用的版權法。在不對版權法所規定的權利加以限制的情況下，如未得到 zhengyun 和 CSDN.Net 明確的書面許可，不得出于任何目的、以任何形式或手段（電子的、機械的、影印、錄制等等）復制、傳播本文的任何部分，也不得將其存儲或引入到檢索系統中。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=12744