寫這篇文章的時(shí)候,還真不知道如何取名,也不知道這個(gè)該如何將其歸類。這個(gè)是同事遇到的一個(gè)案例,案例比較復(fù)雜,這里抽絲剝繭,僅僅構(gòu)造一個(gè)簡(jiǎn)單的案例來(lái)展現(xiàn)一下這個(gè)問(wèn)題。我們先構(gòu)造測(cè)試數(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ù)雜,我們分析、排除掉各個(gè)因素后,始終不得要領(lǐng),各種折騰中發(fā)現(xiàn),如果這樣轉(zhuǎn)換一下(請(qǐng)見下面截圖),居然就OK了,后面分析了一下,應(yīng)該是CASE WHEN里面的不同數(shù)據(jù)類型導(dǎo)致隱式轉(zhuǎn)換,說(shuō)實(shí)話之前還真沒有留意CASE WHEN中存在數(shù)據(jù)類型的隱性轉(zhuǎn)換,但是為什么就一定從NUMERIC轉(zhuǎn)換為INT了呢? 而不是INT隱性轉(zhuǎn)換為NUMERIC呢, 說(shuō)實(shí)話沒有看到相關(guān)文檔的官方,如果按照官方文檔:

當(dāng)兩個(gè)不同數(shù)據(jù)類型的表達(dá)式用運(yùn)算符組合后,優(yōu)先級(jí)較低的數(shù)據(jù)類型首先轉(zhuǎn)換為優(yōu)先級(jí)較高的數(shù)據(jù)類型。 如果此轉(zhuǎn)換不是所支持的隱式轉(zhuǎn)換,則返回錯(cuò)誤。 對(duì)于組合具有相同數(shù)據(jù)類型的操作數(shù)表達(dá)式的運(yùn)算符時(shí),運(yùn)算的結(jié)果便為該數(shù)據(jù)類型
而我們知道,Decimal 和 NUMERIC 是同義詞,可互換使用,而官方文檔“數(shù)據(jù)類型優(yōu)先級(jí) (Transact-SQL)”中,Decimal的優(yōu)先級(jí)明顯高于INT,如果真要按照原理來(lái)解釋,應(yīng)該是INT轉(zhuǎn)換NUMERIC才對(duì)(兩種數(shù)據(jù)類型支持隱式轉(zhuǎn)換),所以越想越糊涂,只知道有這么一回事,但是真正的Root Cause尚不清楚,而且在精確度要求較高的報(bào)表中,這種現(xiàn)象就會(huì)類似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)換問(wèn)題,希望對(duì)大家有所幫助,如果大家有任何疑問(wèn)請(qǐng)給我留言,小編會(huì)及時(shí)回復(fù)大家的。在此也非常感謝大家對(duì)腳本之家網(wǎng)站的支持!
如果你覺得本文對(duì)你有幫助,歡迎轉(zhuǎn)載,煩請(qǐng)注明出處,謝謝!
您可能感興趣的文章:- MySQL的隱式類型轉(zhuǎn)換整理總結(jié)
- MySQL隱式類型的轉(zhuǎn)換陷阱和規(guī)則
- 隱式轉(zhuǎn)換引起的sql慢查詢實(shí)戰(zhàn)記錄