文章主要介紹了SQL Server 中的資料型別隱式轉換問題,本文給大家介紹的非常不錯，具有一定的參考借鑑價值，需要的朋友可以參考下
寫這篇文章的時候，還真不知道如何取名，也不知道這個該如何將其歸類。這個是同事遇到的一個案例，案例比較複雜，這裡抽絲剝繭，僅僅構造一個簡單的案例來展現一下這個問題。我們先構造測試資料，如下所示：
CREATE TABLE TEST
(
ID INT,
GOOD_TYPE VARCHAR(12),
GOOD_WEIGHT NUMERIC(18,2)
)
INSERT INTO dbo.TEST
VALUES( 1, 'T1',1.27)
SELECT GOOD_TYPE,
CASE WHEN ( GOOD_TYPE = 'T1' ) THEN 99.1 + SUM(GOOD_WEIGHT)
ELSE CEILING(SUM(GOOD_WEIGHT))
END AS GrossWeight ,
SUM(GOOD_WEIGHT) AS NetWeight
FROM dbo.TEST
GROUP BY GOOD_TYPE;
如上所示，為什麼99.1 + SUM(GOOD_WEIGHT)變成100了呢？ 原始SQL非常複雜，我們分析、排除掉各個因素後，始終不得要領，各種折騰中發現，如果這樣轉換一下（請見下面截圖），居然就OK了，後面分析了一下，應該是CASE WHEN裡面的不同資料型別導致隱式轉換，說實話之前還真沒有留意CASE WHEN中存在資料型別的隱性轉換，但是為什麼就一定從NUMERIC轉換為INT了呢？ 而不是INT隱性轉換為NUMERIC呢， 說實話沒有看到相關文件的官方，如果按照官方文件：
當兩個不同資料型別的表示式用運算子組合後，優先順序較低的資料型別首先轉換為優先順序較高的資料型別。 如果此轉換不是所支援的隱式轉換，則返回錯誤。 對於組合具有相同資料型別的運算元表示式的運算子時，運算的結果便為該資料型別
而我們知道，Decimal 和 NUMERIC 是同義詞，可互換使用，而官方文件“資料型別優先順序 (Transact-SQL)”中，Decimal的優先順序明顯高於INT，如果真要按照原理來解釋，應該是INT轉換NUMERIC才對（兩種資料型別支援隱式轉換），所以越想越糊塗，只知道有這麼一回事，但是真正的Root Cause尚不清楚，而且在精確度要求較高的報表中，這種現象就會類似Bug一樣的突然出現。需要謹慎留心！
參考資料：
總結
以上所述是小編給大家介紹的SQL Server 中的資料型別隱式轉換問題,希望對大家有所幫助