SQL Server數(shù)據(jù)庫中的數(shù)據(jù)類型隱式轉(zhuǎn)換問題

2019-09-03 14:02:59 來源：瀟湘隱者作者：佚名 人氣： 次閱讀 654 條評論

文章主要介紹了SQL Server 中的數(shù)據(jù)類型隱式轉(zhuǎn)換問題,本文給大家介紹的非常不錯，具有一定的參考借鑒價值，需要的朋友可以參考下寫這篇文章的時候，還真不知道如何取名，也不知道這...

文章主要介紹了SQL Server 中的數(shù)據(jù)類型隱式轉(zhuǎn)換問題,本文給大家介紹的非常不錯，具有一定的參考借鑒價值，需要的朋友可以參考下

寫這篇文章的時候，還真不知道如何取名，也不知道這個該如何將其歸類。這個是同事遇到的一個案例，案例比較復(fù)雜，這里抽絲剝繭，僅僅構(gòu)造一個簡單的案例來展現(xiàn)一下這個問題。我們先構(gòu)造測試數(shù)據(jù)，如下所示：

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非常復(fù)雜，我們分析、排除掉各個因素后，始終不得要領(lǐng)，各種折騰中發(fā)現(xiàn)，如果這樣轉(zhuǎn)換一下（請見下面截圖），居然就OK了，后面分析了一下，應(yīng)該是CASE WHEN里面的不同數(shù)據(jù)類型導(dǎo)致隱式轉(zhuǎn)換，說實話之前還真沒有留意CASE WHEN中存在數(shù)據(jù)類型的隱性轉(zhuǎn)換，但是為什么就一定從NUMERIC轉(zhuǎn)換為INT了呢？ 而不是INT隱性轉(zhuǎn)換為NUMERIC呢， 說實話沒有看到相關(guān)文檔的官方，如果按照官方文檔：

當(dāng)兩個不同數(shù)據(jù)類型的表達(dá)式用運算符組合后，優(yōu)先級較低的數(shù)據(jù)類型首先轉(zhuǎn)換為優(yōu)先級較高的數(shù)據(jù)類型。 如果此轉(zhuǎn)換不是所支持的隱式轉(zhuǎn)換，則返回錯誤。 對于組合具有相同數(shù)據(jù)類型的操作數(shù)表達(dá)式的運算符時，運算的結(jié)果便為該數(shù)據(jù)類型

而我們知道，Decimal 和 NUMERIC 是同義詞，可互換使用，而官方文檔“數(shù)據(jù)類型優(yōu)先級 (Transact-SQL)”中，Decimal的優(yōu)先級明顯高于INT，如果真要按照原理來解釋，應(yīng)該是INT轉(zhuǎn)換NUMERIC才對（兩種數(shù)據(jù)類型支持隱式轉(zhuǎn)換），所以越想越糊涂，只知道有這么一回事，但是真正的Root Cause尚不清楚，而且在精確度要求較高的報表中，這種現(xiàn)象就會類似Bug一樣的突然出現(xiàn)。需要謹(jǐn)慎留心！

參考資料：

https://docs.microsoft.com/zh-cn/sql/t-sql/data-types/data-type-precedence-transact-sql?view=sql-server-2017

https://docs.microsoft.com/zh-cn/sql/t-sql/data-types/data-type-conversion-database-engine?view=sql-server-2017

總結(jié)

以上所述是小編給大家介紹的SQL Server 中的數(shù)據(jù)類型隱式轉(zhuǎn)換問題,希望對大家有所幫助