建站
咨詢
售后
建站咨詢
新聞中心
此文章主要向大家描述的是正確的隱式轉(zhuǎn)換與SQL Server數(shù)據(jù)庫的相關(guān)性能問題，面臨的問題可以對其通過在HumanResources.Employee表的SQL Server 200***dventureWorks數(shù)據(jù)庫中做一個類似的查詢來看到。
創(chuàng)新互聯(lián)建站是一家從事企業(yè)網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計、網(wǎng)站制作、行業(yè)門戶網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計制作的專業(yè)網(wǎng)站設(shè)計公司，擁有經(jīng)驗(yàn)豐富的網(wǎng)站建設(shè)工程師和網(wǎng)頁設(shè)計人員，具備各種規(guī)模與類型網(wǎng)站建設(shè)的實(shí)力，在網(wǎng)站建設(shè)領(lǐng)域樹立了自己獨(dú)特的設(shè)計風(fēng)格。自公司成立以來曾獨(dú)立設(shè)計制作的站點(diǎn)上1000+。
為了幫助我們更好地理解SQL Server在我們運(yùn)行這些查詢時都做了什么，讓我們來查找IO統(tǒng)計數(shù)據(jù)，
我面臨的問題可以通過在HumanResources.Employee表的SQL Server 200***dventureWorks數(shù)據(jù)庫中做一個類似的查詢來看到。為了幫助我們更好地理解SQL Server在我們運(yùn)行這些查詢時都做了什么，讓我們來查找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行，因此這可能真的可以很快地運(yùn)行并且看似不會造成什么問題。我使用的表有數(shù)百萬行，表掃描正是兇手，因?yàn)樗鼘τ诿看尾樵兌家◣酌氲臅r間。
由于NationalIDNumber字段在索引以及該索引***字段的開頭，那么為什么這里只有一個掃描而沒有查找呢?下面的查詢機(jī)壞昂告訴我們?yōu)槭裁础＿@是你可以看到索引掃描的整個計劃：
該索引掃描的工具技巧給出所有不同點(diǎn)的詳細(xì)信息，如下所示：
紅色箭頭指向了該問題。函數(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)在顯示為零掃描，這正是我們想要的。在這個案例中，邏輯讀的不同點(diǎn)是只有2，這是因?yàn)镋mployee很小。如果在數(shù)百萬行的表上進(jìn)行這個過程，那么邏輯讀的不同點(diǎn)將變成幾千。
- 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ù)庫將很忠實(shí)地執(zhí)行隱式轉(zhuǎn)換并返回正確的結(jié)果，但是要以較差的性能為代價，通過一個掃描而不是查找來進(jìn)行并且要正確使用該索引。
下一步
要一直警惕隱式轉(zhuǎn)換，尤其是有存儲數(shù)字型鍵的字符串的時候。
我甚至在varchar字段與nvarchar字段進(jìn)行比較的時候看到這個問題。
更正這個問題是很簡單的，你只需要確保在相似的數(shù)據(jù)類型上執(zhí)行比較。
【編輯推薦】
- SQL Serverlink Oracle的幾種不同方式
- SQL Server Compact中的DLL文件與工具
- SQL Server數(shù)據(jù)庫在安裝時的注意事項(xiàng)
- SQL Server 2005 Express混合模式登錄的設(shè)置
- SQL Server 2005數(shù)據(jù)庫安裝實(shí)例演示
網(wǎng)站欄目：SQL Server數(shù)據(jù)庫的相關(guān)性能問題與隱式轉(zhuǎn)換
URL網(wǎng)址：http://m.5511xx.com/article/cdiphed.html
