日韩电影天堂网在线观看,男人天堂b,国产性夜夜春夜夜爽30

【SQLServer】使用SQL執(zhí)行計(jì)劃進(jìn)行性能調(diào)優(yōu)

當(dāng)前位置：點(diǎn)晴教程→知識(shí)管理交流 →『技術(shù)文檔交流』

freeflydom

2023年11月27日 11:51 本文熱度 670

SQL執(zhí)行計(jì)劃中會(huì)有許多跡象表明查詢中可能存在不良性能點(diǎn)。例如，與整體查詢成本相關(guān)的成本最高的最昂貴運(yùn)算符是查詢性能故障排除的良好起點(diǎn)。此外，后面跟著細(xì)箭頭的粗箭頭表示正在處理大量記錄并從一個(gè)運(yùn)算符流向另一個(gè)運(yùn)算符以檢索少量記錄，這也可能是缺少索引或性能問題的標(biāo)志。

在了解了本系列中討論的每個(gè)計(jì)劃運(yùn)算符的作用之后，你可以識(shí)別出由于額外開銷而降低查詢性能的額外運(yùn)算符。此外，用于掃描整個(gè)表或索引的Scan運(yùn)算符表明大多數(shù)情況下存在缺少索引、索引使用不當(dāng)或查詢不包含過濾條件。執(zhí)行計(jì)劃中查詢中性能問題的另一個(gè)標(biāo)志是執(zhí)行計(jì)劃警告。這些消息用于警告查詢的不同問題以進(jìn)行故障排除，例如tempdb溢出問題、缺少索引或錯(cuò)誤的基數(shù)估計(jì)。

要了解如何使用SQL執(zhí)行計(jì)劃來調(diào)整性能，讓我們通過我們的實(shí)例演示。在開始第一個(gè)示例之前，我們將使用以下create TABLE語句創(chuàng)建兩個(gè)新表：

create TABLE Employee_Main

( Emp_ID INT IDENTITY (1,1) PRIMARY KEY,

EMP_FirsrName VARCHAR (50),

EMP_LastName VARCHAR (50),

EMP_BirthDate DATETIME,

EMP_PhoneNumber VARCHAR (50),

EMP_Address VARCHAR (MAX)

)

GO

create TABLE EMP_Salaries

( EMP_ID INT IDENTITY (1,1),

EMP_HireDate DATETIME,

EMP_Salary INT,

CONSTRAINT FK_EMP_Salaries_Employee_Main FOREIGN KEY (EMP_ID)

REFERENCES Employee_Main (EMP_ID),

)

GO

然后使用ApexSQL Generate向每個(gè)表中插入100k條記錄

調(diào)優(yōu)簡(jiǎn)單的查詢
假設(shè)我們需要調(diào)優(yōu)以下表現(xiàn)不佳的select語句的性能：

select [EMP_ID]

,[EMP_HireDate]

,[EMP_Salary]

from [AdventureWorks2016CTP3].[dbo].[EMP_Salaries]

where [EMP_ID]< 1000

調(diào)優(yōu)查詢性能的最佳方法是研究該查詢的SQL執(zhí)行計(jì)劃。執(zhí)行前面的查詢：

從生成的計(jì)劃中可以清楚地看出，SQL Server引擎掃描所有表行(100K 記錄)以檢索請(qǐng)求的數(shù)據(jù)(1 條記錄)。從三個(gè)跡象可以看出這一點(diǎn)：
·表掃描運(yùn)算符
·該運(yùn)算符的高成本
·以及從將數(shù)據(jù)從表掃描流到下一個(gè)運(yùn)算符的粗箭頭轉(zhuǎn)換到流輸出數(shù)據(jù)的細(xì)箭頭。

使用ApexSQL Plan，可以檢查查詢的執(zhí)行統(tǒng)計(jì)信息，例如該查詢的讀次數(shù)、持續(xù)時(shí)間和CPU成本，如下所示：

從計(jì)劃中得出的三個(gè)標(biāo)志將我們引向查詢性能不佳的主要原因，即EMP_Salary表中沒有索引，索引可以加快從該表中檢索數(shù)據(jù)的過程。我們將繼續(xù)使用下面的create INDEX語句在EMP_Salary表的EMP_ID列上創(chuàng)建索引：

1	`create` `NONCLUSTERED` `INDEX` `IX_EMP_Salaries_EMP_ID` `ON` `EMP_Salaries (EMP_ID)`

…然后運(yùn)行相同的語句。

從生成的執(zhí)行計(jì)劃中可以看出，SQL Server Engine會(huì)直接在創(chuàng)建的索引中尋找請(qǐng)求的數(shù)據(jù)，無需掃描整個(gè)底層表，Index Seek的成本降低到50%。此外，從Index Seek運(yùn)算符流向下一個(gè)運(yùn)算符的記錄數(shù)明顯減少，從箭頭的粗細(xì)可以看出，如下圖所示：

檢查執(zhí)行計(jì)劃的統(tǒng)計(jì)信息，將看到行數(shù)如何減少到2，而持續(xù)時(shí)間和CPU成本可以忽略不計(jì)，如下所示：

如果深入查看之前的計(jì)劃，你會(huì)發(fā)現(xiàn)另一個(gè)性能問題的跡象，即額外昂貴的RID查找和嵌套循環(huán)運(yùn)算符。SQL Server引擎使用非聚集索引檢索EMP_ID列并返回基礎(chǔ)表以檢索其余列。這個(gè)問題可以通過創(chuàng)建一個(gè)覆蓋索引來解決，它允許SQL Server引擎從該有序的索引中檢索所有列，而無需檢查基礎(chǔ)表。

下面的create INDEX語句可用于為該查詢創(chuàng)建覆蓋索引：

1	`create` `NONCLUSTERED` `INDEX` `IX_EMP_Salaries_EMP_ID` `ON` `EMP_Salaries (EMP_ID) INCLUDE (EMP_HireDate,EMP_Salary )` `WITH` `drop_EXISTING`

運(yùn)行相同的select語句，將看到不再出現(xiàn)RID Lookup和Nested Loops運(yùn)算符，因?yàn)镾QL Server引擎在索引中找到了所有請(qǐng)求的數(shù)據(jù)，如下所示：

調(diào)優(yōu)復(fù)雜查詢

我們看到了SQL執(zhí)行計(jì)劃如何幫助我們調(diào)優(yōu)簡(jiǎn)單查詢的性能。它會(huì)以同樣的方式幫助我們進(jìn)行更復(fù)雜的查詢的調(diào)優(yōu)嗎？

讓我們刪除在EMP_Salaries表上創(chuàng)建的索引：

1	`drop` `INDEX` `IX_EMP_Salaries_EMP_ID` `ON` `EMP_Salaries`

假設(shè)我們需要調(diào)整以下查詢的性能，該查詢連接之前創(chuàng)建的兩個(gè)EMP測(cè)試表，以檢索員工的信息：

select EMP_FirsrName, EMP_LastName, EMP_BirthDate, EMP_Address, EMP_HireDate, EMP_Salary

from [dbo].[Employee_Main] EM

JOIN [dbo].[EMP_Salaries] ES

ON EM.[EMP_ID] =ES.[EMP_ID]

where EM.[EMP_ID] > 2470 AND ES.EMP_Salary >450

如果執(zhí)行查詢，你會(huì)從生成的計(jì)劃中看到一些性能問題的跡象，比如Table Scan運(yùn)算符，由于掃描了整個(gè)底層表；粗箭頭，由于大量的行在運(yùn)算符之間流動(dòng)以及額外昂貴的運(yùn)算符，例如Hash Match運(yùn)算符，如下面的SQL執(zhí)行計(jì)劃所示：