此文章主要向大家描述的是正確的隱式轉(zhuǎn)換與SQL Server數(shù)據(jù)庫的相關(guān)性能問題，面臨的問題可以對其通過在HumanResources.Employee表的SQL Server 200***dventureWorks數(shù)據(jù)庫中做一個類似的查詢來看到。

為了幫助我們更好地理解SQL Server在我們運行這些查詢時都做了什么，讓我們來查找IO統(tǒng)計數(shù)據(jù)，

我面臨的問題可以通過在HumanResources.Employee表的SQL Server 200***dventureWorks數(shù)據(jù)庫中做一個類似的查詢來看到。為了幫助我們更好地理解SQL Server在我們運行這些查詢時都做了什么，讓我們來查找IO統(tǒng)計數(shù)據(jù)，并且使用SSMS菜單命令Query\Include Actual Execution Plan。

為了使用AdventureWorks數(shù)據(jù)庫并且啟用IO統(tǒng)計數(shù)據(jù)，讓我們從下面的查詢開始：

use AdventureWorks   
go  
SET STATISTICS IO ON  
go  

這是對Employee表的一個查詢，它類似于給我?guī)砩鲜雎闊┑牟樵儯?/p>

SELECT EmployeeID, NationalIDNumber, LoginID   
FROM HumanResources.Employee  
WHERE NationalIDNumber = 112457891 
go  

它看起來似乎不會給我們帶來什么麻煩。HumanResources.Employee表有一個以NationalIDNumber開始的索引，因此執(zhí)行這個查詢只是查找112457891的位置然后對這個表的行作查找。但是統(tǒng)計數(shù)據(jù)和查詢計劃顯示了事情并非如此簡單。這是相關(guān)的信息：

EmployeeID NationalIDNumber LoginID   
4 112457891 adventure-works\rob0  
(1 row(s) affected)  
Table 'Employee'. Scan count 1, logical reads 6,  
physical reads 0, read-ahead reads 0,  
lob logical reads 0, lob physical reads 0,  
lob read-ahead reads 0.  
(1 row(s) affected)  

該統(tǒng)計數(shù)據(jù)顯示有一個掃描，而這正是問題所在。Adventureworks.HumanResources.Employee只有291行，因此這可能真的可以很快地運行并且看似不會造成什么問題。我使用的表有數(shù)百萬行，表掃描正是兇手，因為它對于每次查詢都要花幾秒的時間。

由于NationalIDNumber字段在索引以及該索引***字段的開頭，那么為什么這里只有一個掃描而沒有查找呢?下面的查詢機壞昂告訴我們?yōu)槭裁?。這是你可以看到索引掃描的整個計劃：

該索引掃描的工具技巧給出所有不同點的詳細信息，如下所示：

紅色箭頭指向了該問題。函數(shù)CONVERT_IMPLICIT(int, [AdventureWorks].[HumanResources].[Employee].[NationalIDNumber, 0)在它與我們傳遞到該查詢中的整數(shù)常數(shù)1124579811比較之前修改了NationalIDNumber字段。如果你查看這張表的定義，那么你就會看到NationalIDNumber被定義成nvarchar(15)。一旦這里有個函數(shù)，即使是我們在這里看到的自帶函數(shù)用于這個字段，SQL Server數(shù)據(jù)庫都不能在NationalDNumber上使用索引，它會返回到一個掃描中。

更改這個查詢來與一個字符串常數(shù)比較，這個問題將得到解決：

SELECT EmployeeID, NationalIDNumber, LoginID   
FROM HumanResources.Employee  
WHERE NationalIDNumber = '112457891' 
go  

這些信息現(xiàn)在顯示為零掃描，這正是我們想要的。在這個案例中，邏輯讀的不同點是只有2，這是因為Employee很小。如果在數(shù)百萬行的表上進行這個過程，那么邏輯讀的不同點將變成幾千。

EmployeeID NationalIDNumber LoginID   
4 112457891 adventure-works\rob0  
(1 row(s) affected)  
Table 'Employee'. Scan count 0, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.  
(1 row(s) affected)  

查詢計劃顯示查找和主鍵查找正是我們希望看到的。

一個字符串用于存儲一個數(shù)字型主鍵的問題是很常見的。SQL Server數(shù)據(jù)庫將很忠實地執(zhí)行隱式轉(zhuǎn)換并返回正確的結(jié)果，但是要以較差的性能為代價，通過一個掃描而不是查找來進行并且要正確使用該索引。

下一步

要一直警惕隱式轉(zhuǎn)換，尤其是有存儲數(shù)字型鍵的字符串的時候。

我甚至在varchar字段與nvarchar字段進行比較的時候看到這個問題。

更正這個問題是很簡單的，你只需要確保在相似的數(shù)據(jù)類型上執(zhí)行比較。

【編輯推薦】

1. SQL Serverlink Oracle的幾種不同方式
2. SQL Server Compact中的DLL文件與工具
3. SQL Server數(shù)據(jù)庫在安裝時的注意事項
4. SQL Server 2005 Express混合模式登錄的設(shè)置
5. SQL Server 2005數(shù)據(jù)庫安裝實例演示