通過觀察執(zhí)行計劃,發(fā)現之前的執(zhí)行計劃在很多大表連接的部分使用了Hash Join,由于涉及的表中數據眾多,因此查詢優(yōu)化器選擇使用并行執(zhí)行,速度較快。而我們優(yōu)化完的執(zhí)行計劃由于索引的存在,且表內數據非常大,過濾條件的值在一個很寬的統(tǒng)計信息步長范圍內,導致估計行數出現較大偏差(過濾條件實際為15000行,步長內估計的平均行數為800行左右),因此查詢優(yōu)化器選擇了Loop Join,且沒有選擇并行執(zhí)行,因此執(zhí)行時間不降反升。
由于語句是在存儲過程中實現,因此我們直接對該語句使用一個undocument查詢提示,使得該查詢的并行開銷閾值強制降為0,使得該語句強制走并行,語句執(zhí)行時間由20秒降為5秒(注:使用Hash Join提示是7秒)。
下面通過一個簡單的例子展示使用該提示的效果,示例T-SQL如代碼清單1所示:
SELECT *
FROM [AdventureWorks].[Sales].[SalesOrderDetail] a
INNER JOIN [Sales].SalesOrderHeader b
ON a.SalesOrderID=b.SalesOrderID
代碼清單1.
該語句默認不會走并行,執(zhí)行計劃如圖1所示:

圖1.
下面我們對該語句加上提示,如代碼清單2所示。
SELECT *
FROM [AdventureWorks].[Sales].[SalesOrderDetail] a
INNER JOIN [Sales].SalesOrderHeader b
ON a.SalesOrderID=b.SalesOrderID
OPTION(querytraceon 8649)
代碼清單2.
此時執(zhí)行計劃會按照提示走并行,如圖2所示:

圖2.
在面對一些復雜的DSS或OLAP查詢時遇到類似的情況,可以考慮使用該Undocument提示要求SQL Server盡可能的使用并行,從而降低執(zhí)行時間。
您可能感興趣的文章:- 淺析SQL Server 聚焦索引對非聚集索引的影響
- MySQL中主鍵索引與聚焦索引之概念的學習教程
- SQLSERVER中得到執(zhí)行計劃的兩種方式
- SqlServer 執(zhí)行計劃及Sql查詢優(yōu)化初探
- SQL Server中參數化SQL寫法遇到parameter sniff ,導致不合理執(zhí)行計劃重用的快速解決方法
- 淺析SQL Server中的執(zhí)行計劃緩存(下)
- 淺析SQL Server中的執(zhí)行計劃緩存(上)
- 淺析SQL Server的聚焦使用索引和查詢執(zhí)行計劃