小議隱式轉換引發的問題

隱式轉換（Implicit conversion） ，這個狀況每一個程序員都或多或少的遇到過，這裏我結合實際狀況簡單描述下常見的問題以及如何解決並闡述下原理。

所謂隱式轉換主要出如今咱們T-SQL語句中的where 條件裏面，咱們先從緣由上去看一下爲何會出現隱式轉換。

出現隱式轉換的狀況和結果：

當SQL server遇到一個不匹配類型的表達式的時候，它有兩種可能：1.使用隱式轉換並可以執行；2.轉換錯誤而致使執行失敗。

在進行以前，咱們先提出一個概念：

數據類型優先級

當兩個不一樣數據類型的表達式用運算符組合後，數據類型優先級規則指定將優先級較低的數據類型轉換爲優先級較高的數據類型。

若是此轉換不是所支持的隱式轉換，則返回錯誤。 當兩個操做數表達式具備相同的數據類型時，運算的結果便爲該數據類型。

SQL Server 對數據類型使用如下優先級順序：                       

1. 用戶定義數據類型（最高）                               
2. sql_varian   t                                
3. xml                                                  
4. datetimeoffset                                                  
5. datetime2                                                  
6. datetime                                                  
7. smalldatetime                                                  
8. date                                                  
9. time                                                  
10. float                                                  
11. real                                                  
12. decimal                                                  
13. money                                                  
14. smallmoney                                                  
15. bigint                                                  
16. int                                                  
17. smallint                                                  
18. tinyint                                                  
19. bit                                                  
20. ntext                                                  
21. text                                                  
22. image                                                  
23. timestamp                                                  
24. uniqueidentifier                                                  
25. nvarchar（包括 nvarchar(max)）                               
26. nchar                                                  
27. varchar（包括 varchar(max)）                               
28. char                                                  
29. varbinary（包括 varbinary(max)）                               
30. binary（最低）                

1.隱式轉換成功的狀況下有兩種狀況，咱們結合執行計劃來看一下

主鍵爲int 類型和主鍵爲varchar類型的狀況下隱式轉換有什麼不一樣

         

圖1.SalesOrderId主鍵爲Int類型                                                                            圖2.SalesOrderId主鍵爲varchar類型    

經過執行sql語句和執行計劃咱們很容易發現，當主鍵爲Int類型的時候，咱們的參數爲varchar類型，結果採用了彙集索引查找，效率較高（圖1）；

而圖2，主鍵改成varchar類型，參數改成int類型執行計劃採用了非彙集索引掃描，IO勢必增長很多。

結合咱們以前提出的優先級概念，得知若是參數的數據類型較低則隱式轉換後採用了正確的優化，即無損轉換，而當參數優先級較低的時候則對性能產生了損耗。

下面咱們看一下詳細的執行計劃來做證上面的觀點：

有這個對比能夠發現一個是對參數進行了轉換，一個是對數據表的字段進行了轉換，能夠想象由此得出的問題。

 固然咱們也能夠經過轉換參數的類型的方式來解決這個問題，可是由與精度不一樣有時候會產生問題，好比轉換一個REAL型到INT整型

 CONVERT(INT,@Real);須要注意的是聯接叢書頁面中涵蓋了一個兼容性矩陣，描述了SQL server如何處理數據類型轉換的全部可能性，意思就

是說並不是全部的隱式轉換均可行，有些轉換是不被容許的。簡單說基本上， 有三種比較表達式選項：

　　1.轉換右側數據類型爲左側數據類型。

　　2.轉換左側數據類型爲右左側數據類型。

　　3.將二者轉換到第三方數據類型

這部分就不一一贅述了。

總結： 本文主要介紹了隱式轉換產生的緣由及原理，實例證實了對於查詢效率產生了明顯的影響。具體解決上要根據實際狀況進行數據類型的轉換或者注意類型的兼容性和優先級。因爲隱式轉換查詢帶來的性能問題甚至因爲主鍵掃描帶來的鎖的問題，都須要開發人員瞭解這部分的原理，從根源上避免這類事件的發生。