主頁(yè) > 知識(shí)庫(kù) > SQL Server里書(shū)簽查找的性能傷害

SQL Server里書(shū)簽查找的性能傷害

熱門(mén)標(biāo)簽:互聯(lián)網(wǎng)電話外呼系統(tǒng) 400電話辦理泰安 電銷(xiāo)需要外呼系統(tǒng)嗎 電話機(jī)器人怎么代理商 千呼電話機(jī)器人可以試用嗎 零成本地圖標(biāo)注賺錢(qián) 安卡拉地圖標(biāo)注app 家庭農(nóng)場(chǎng)地圖標(biāo)注名稱(chēng)怎樣起名 我要地圖標(biāo)注數(shù)量有限制嗎

在我的博客上,以前我經(jīng)常談到SQL Serverl里的書(shū)簽查找,還有它們帶來(lái)的很多問(wèn)題。在今天的文章里,我想從性能角度進(jìn)一步談下書(shū)簽查找,還有它們?nèi)绾卫湍阏麄€(gè)SQL Server性能。

書(shū)簽查找——反復(fù)循環(huán)

如果你的非聚集索引不是個(gè)覆蓋非聚集索引,SQL Server的查詢(xún)優(yōu)化器會(huì)引入書(shū)簽查找。對(duì)于從非聚集索引你返回的每一行,SQL Server需要在聚集索引里或堆表里進(jìn)行額外的查找操作。

例如當(dāng)你的的聚集索引包含3層,為了返回必要的信息,對(duì)于每一行,你需要3頁(yè)額外的讀取。因此,查詢(xún)優(yōu)化器再執(zhí)行計(jì)劃里選擇書(shū)簽查找操作,僅在有意義的時(shí)候發(fā)生——基于你查詢(xún)的選擇度。下圖展示了有書(shū)簽查找操作的執(zhí)行計(jì)劃。

通常人們不會(huì)太關(guān)注書(shū)簽查找,因?yàn)樗鼈冎粓?zhí)行幾次。如果你的查詢(xún)選擇度太低,查詢(xún)優(yōu)化器會(huì)用聚集索引掃描或表掃描運(yùn)算符直接掃描整個(gè)表。但只在SQL Server重用緩存的執(zhí)行計(jì)劃,這個(gè)計(jì)劃是有多次不同運(yùn)行值,包含書(shū)簽查找的(基于最初提供的輸入值),因此這個(gè)情況很容易發(fā)生,書(shū)簽查找反復(fù)執(zhí)行。

為了演示這個(gè)性能問(wèn)題,接下來(lái)的查詢(xún)我指定查詢(xún)優(yōu)化器使用特定的非聚集索引。查詢(xún)本身返回80000行,因?yàn)閷?duì)于每個(gè)查詢(xún)執(zhí)行,SQL Server需要進(jìn)行書(shū)簽查找80000次——反復(fù)執(zhí)行。

CREATE PROCEDURE RetrieveData
AS
 SELECT * FROM Table1 WITH (INDEX(idxTable1_Column2))
 WHERE Column3 = 2
GO

下圖展示了查詢(xún)執(zhí)行后的實(shí)際執(zhí)行計(jì)劃。

執(zhí)行計(jì)劃看起來(lái)非??植溃ú樵?xún)優(yōu)化器甚至啟用了并行計(jì)劃!),因?yàn)闀?shū)簽查找運(yùn)算符這里執(zhí)行了80000次,查詢(xún)本身產(chǎn)生了超過(guò)165000個(gè)邏輯讀?。ㄟ壿嬜x個(gè)數(shù)可以從STATISTIC IO里獲?。?。

接下來(lái)向你展示下,當(dāng)你有很多并行用戶執(zhí)行這個(gè)糟糕查詢(xún)時(shí),SQL Server會(huì)發(fā)生什么。我會(huì)使用ostress.exe(RML工具的一部分)來(lái)模擬100個(gè)并行用戶的查詢(xún)。

ostress.exe -Q”EXEC BookmarkLookupsPerformance.dbo.RetrieveData” -n100 -q

在我的測(cè)試系統(tǒng)上花費(fèi)了近15秒來(lái)完成100個(gè)并行查詢(xún)。在此期間,CPU占用很高,因?yàn)镾QL Server需要嵌套循環(huán)運(yùn)算符來(lái)進(jìn)行書(shū)簽查找操作。嵌套循環(huán)操作當(dāng)然很占CPU資源。

現(xiàn)在讓我們修改索引設(shè)計(jì),為這個(gè)查詢(xún)創(chuàng)建覆蓋非聚集索引。有了非聚集索引,查詢(xún)優(yōu)化器不需要再執(zhí)行計(jì)劃里進(jìn)行書(shū)簽查找。一個(gè)非聚集索引查找就可以返回同樣的結(jié)果:

CREATE NONCLUSTERED INDEX idxTable1_Column2 ON Table1(Column3)
INCLUDE (Column2)
WITH (DROP_EXISTING = ON)
GO

這次當(dāng)我們?cè)俅斡胦stress.exe執(zhí)行同個(gè)查詢(xún),我們看到每個(gè)查詢(xún)?cè)?秒內(nèi)完成。和我們剛才看到的15秒有很大的區(qū)別。這就是覆蓋非聚集索引的威力:在我們查詢(xún)里氣門(mén)請(qǐng)求的數(shù)據(jù)都可以在非聚集索引里直接找到,因此書(shū)簽查找就可以避免。

小結(jié)

在這個(gè)文章里我向你展示了不好的書(shū)簽查找會(huì)傷及性能。因此,對(duì)于重要的查詢(xún)快速完成查詢(xún)非常重要——而使用并行的書(shū)簽查找的執(zhí)行計(jì)劃并不是好的選擇。這里覆蓋非聚集索引可以幫到你。下次設(shè)計(jì)索引時(shí)可以考慮下這個(gè)方法。

以上就是本文的全部?jī)?nèi)容,希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作能帶來(lái)一定的幫助,同時(shí)也希望多多支持腳本之家!

您可能感興趣的文章:
  • Sql Server查詢(xún)性能優(yōu)化之不可小覷的書(shū)簽查找介紹

標(biāo)簽:黃山 來(lái)賓 池州 濱州 新鄉(xiāng) 東營(yíng) 文山 大同

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《SQL Server里書(shū)簽查找的性能傷害》,本文關(guān)鍵詞  SQL,Server,里,書(shū)簽,查找,的,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無(wú)關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《SQL Server里書(shū)簽查找的性能傷害》相關(guān)的同類(lèi)信息!
  • 本頁(yè)收集關(guān)于SQL Server里書(shū)簽查找的性能傷害的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章