前言

本篇繼續(xù)玩轉(zhuǎn)模塊的內(nèi)容，關(guān)于索引在SQL Server的位置無須多言，本篇將分析如何利用Hint引導(dǎo)語句充分利用索引進(jìn)行運(yùn)行，同樣，還是希望扎實(shí)掌握前面一系列的內(nèi)容，才進(jìn)入本模塊的內(nèi)容分析。

閑言少敘，進(jìn)入本篇的內(nèi)容。

技術(shù)準(zhǔn)備

數(shù)據(jù)庫版本為SQL Server2012，利用微軟的以前的案例庫（Northwind）進(jìn)行分析，部分內(nèi)容也會應(yīng)用微軟的另一個(gè)案例庫AdventureWorks。

相信了解SQL Server的朋友，對這兩個(gè)庫都不會太陌生。

一、并行Hint提示（MAXDOP N Hint）

在當(dāng)前多核超線程的今天，并行運(yùn)算已經(jīng)不算什么稀罕了，所以在SQL Server中也有它自己的并行運(yùn)算符，來充分的利用現(xiàn)有硬件資源，最大限度的提升運(yùn)行效率。

在本系列中有兩篇文章專門介紹關(guān)于SQL Server的并行運(yùn)算，可以點(diǎn)擊查看：SQL Server并行運(yùn)算總結(jié)、SQL Server并行運(yùn)算總結(jié)篇二

所以，在Hint中也給出了關(guān)于并行運(yùn)算的提示：MAXDOP N Hint，這個(gè)Hint還是經(jīng)常用的，尤其索引操作的時(shí)候，為了縮短操作時(shí)間，我們常常會最大限度的利用并行運(yùn)算。

另外，此Hint會優(yōu)先于數(shù)據(jù)庫級別的配置選項(xiàng)。也就說盡管在數(shù)據(jù)庫中設(shè)置了MAXDOP 1(強(qiáng)制順序運(yùn)行)，如果使用了此Hint也會忽略數(shù)據(jù)庫設(shè)置的。

當(dāng)然，并行運(yùn)算雖然大部分情況能提升運(yùn)行效率，但是也非絕對，我們知道多線程的操作是需要維護(hù)線程之間的數(shù)據(jù)交換和執(zhí)行順序等，所有有時(shí)候多線程的執(zhí)行并不一定會單線程效率高。

來看個(gè)例子：

SELECT [KEY],[DATA]FROM TestMaxDopTableWHERE DATA<1000OPTION(MAXDOP 1)SELECT [KEY],[DATA]FROM TestMaxDopTableWHERE DATA<1000OPTION(MAXDOP 4)

上面為串行運(yùn)算，下面為4線程的并行運(yùn)算。

當(dāng)然，此處幾線程運(yùn)算可以自己設(shè)定，最大值推薦為當(dāng)前系統(tǒng)配置的邏輯核數(shù)，當(dāng)然設(shè)置大了也可以只不過沒用罷了。

二、索引Hint提示（INDEX Hint）

所謂的索引Hint提示，就是強(qiáng)制查詢優(yōu)化器為一個(gè)查詢語句執(zhí)行掃描或者使用一個(gè)指定的索引。

此方式，是我們在調(diào)優(yōu)中經(jīng)常用到的一種方式，很多時(shí)候我們創(chuàng)建的索引是失效的，當(dāng)然，大部分情況下失效的原因是創(chuàng)建索引不妥當(dāng)導(dǎo)致的，但是有一些情況下，需要我們來指導(dǎo)下T-SQL的運(yùn)行方式，這時(shí)候就是索引Hint的使用場景了。

當(dāng)然，這里能利用索引提示的前提就是當(dāng)前表存在索引了，如果是堆表的情況，根本就談不上了索引提示了，只能通過表掃描獲取數(shù)據(jù)了。

來看看這個(gè)提示的用法：WITH(INDEX(N))

這里的N就是索引的在該表中索引順序排序號了，來看一張表中的索引序列號：

SELECT * FROM SYS.indexesWHERE OBJECT_NAME(object_id)='Orders'

可以看到，該表中存在十個(gè)索引，依次排序之后，就是從1至10，第一個(gè)就是聚集索引（主鍵）了，然后是非聚集索引。

所以，我們上面的N的值就是這個(gè)數(shù)字了，指定幾就是要求用哪個(gè)索引了。

來看個(gè)腳本：

SELECT OrderID,CustomerIDFROM Orders WITH(INDEX(1))WHERE ShipPostalCode=N'99362'SELECT OrderID,CustomerIDFROM Orders WITH(INDEX(9))WHERE ShipPostalCode=N'99362'

看到了，上面的例子中我們選了兩個(gè)索引：一個(gè)編號1的聚集索引PK_Orders，一個(gè)編號為9的非聚集索引了ShipPostalCode。當(dāng)然，有興趣也可以玩玩其它幾個(gè)索引。

我們順便來分析下這個(gè)語句的索引用法：

首先從查詢條件來看，我們是根據(jù)ShipPostalCode進(jìn)行查詢，所以最好在該列中被索引所覆蓋，這樣在數(shù)據(jù)量大的情況下，查詢優(yōu)化器就可以采用索引查找（Index Seek）了，所以，這里我們選擇了第9個(gè)非聚集索引，恰巧覆蓋該列值，從上面的查詢計(jì)劃也可以看出，采用該索引Hint提示后查詢開銷從69%提升至3%...但是由于這個(gè)非聚集索引沒有包含CustomerID列，所以不得不又引入書簽查找（key Lookup）來獲取該列值，并且這個(gè)書簽查找消耗還比較大：60%，所以最佳的方式就是將該索引Include進(jìn)CustomerID列。

當(dāng)然，此方式用起來可能很不爽，因?yàn)槲覀冊谑褂玫臅r(shí)候需要查找當(dāng)前表中的各個(gè)索引的排序號。

所以，我們最推薦也是最常用的方式是這樣：

WITH(INDEX('IndexName'))

就是我們直接指定索引名稱既可以，來看個(gè)例子：

SELECT OrderID,CustomerIDFROM Orders WITH(INDEX(CustomersOrders))WHERE ShipPostalCode=N'99362'

看起來，簡單的多了，因?yàn)樗饕拿治覀冎苯幽芸吹剑瑏砜纯次覀儗⑦@個(gè)查詢語句指定到這個(gè)非聚集索引CustomersOrders上的執(zhí)行計(jì)劃。

來看看這個(gè)查詢計(jì)劃：丫的！.....查詢開銷直接飆升到100%......原因很簡單：這個(gè)非聚集索引和這個(gè)查詢一毛錢關(guān)系....但是我們卻強(qiáng)制的指定該語句利用索引執(zhí)行....

首先非聚集索引包含的列為：[OrderID]，[CustomerID]

我們要獲取的值為按照ShipPostalCode進(jìn)行篩選，所以要獲取結(jié)果就必須按照這個(gè)非聚集索引進(jìn)行一次掃描（Index Scan），這個(gè)還可以，畢竟非聚集索引都是有序進(jìn)行的，但是為了進(jìn)行過濾，就必須引入書簽查找（Key Lookup）進(jìn)行過濾，我們知道書簽查找為隨機(jī)IO，消耗巨大，所以這次過濾就好比在整張表中隨機(jī)的去查找數(shù)據(jù)一樣，其實(shí)效率還不如來一次表掃描（Table Scan）的好，所以此開銷飆升到95%！

上面的例子，也是很多新手容易犯的錯誤。

我記得在玩轉(zhuǎn)模塊的第一篇中，我們提到過一個(gè)利用OPTIMIZE FORHint提示解決一個(gè)引入?yún)?shù)而導(dǎo)致的執(zhí)行計(jì)劃評估不準(zhǔn)的問題。

文章可以點(diǎn)擊此處看到：SQL Server調(diào)優(yōu)系列玩轉(zhuǎn)篇（如何利用查詢提示（Hint）引導(dǎo)語句運(yùn)行）

我們來回顧下：

--普通的查詢語句SELECT OrderID,OrderDateFROM OrdersWHERE ShipPostalCode=N'51100'--參數(shù)化后的查詢語句DECLARE  @ShipPostalCode NVARCHAR(50)SET @ShipPostalCode=N'51100'SELECT OrderID,OrderDateFROM OrdersWHERE ShipPostalCode=@ShipPostalCode

完全相同邏輯的查詢語句，只是下面那個(gè)我們通過參數(shù)進(jìn)行了傳值操作。

我們只是加了一個(gè)參數(shù)，SQL Server將相同的查詢語句，有以前的索引查找變成了索引掃描了！

消耗一下子從46%提升到54%.....這也是我們寫的語句經(jīng)常遇到的問題，因?yàn)楹芏嗲闆r下，我們都是通過傳參來實(shí)現(xiàn)該語句的重用性。

但是，為什么加了參數(shù)使得查詢性能變差，顯然不是一個(gè)好的方式，在第一篇的玩轉(zhuǎn)篇中，我們的解決方式是通過OPTIMIZE FORHint提示解決。

這里，我們再來看一個(gè)解決方式，也可以通過索引Hint來強(qiáng)制該語句指定按照給定的索引進(jìn)行查找。

方法如下：

--參數(shù)化后的查詢語句DECLARE  @ShipPostalCode NVARCHAR(50)SET @ShipPostalCode=N'51100'SELECT OrderID,OrderDateFROM Orders WITH(INDEX(ShipPostalCode))WHERE ShipPostalCode=@ShipPostalCode

是不是一個(gè)很帥的方式。

希望你能理解這些個(gè)方式的好處，算作拋磚引玉了。

結(jié)語

此篇文章先到此吧，到此玩轉(zhuǎn)篇已經(jīng)三篇了，關(guān)于SQL Server調(diào)優(yōu)工具Hint的使用還有很多內(nèi)容，后續(xù)依次介紹，有興趣的童鞋可以提前關(guān)注。

有問題可以留言或者私信，隨時(shí)恭候有興趣的童鞋加入SQL SERVER的深入研究。共同學(xué)習(xí)，一起進(jìn)步。

文章最后給出前面幾篇的連接，以下內(nèi)容基本涵蓋我們?nèi)粘Ｖ兴鶎懙牟樵冞\(yùn)算的分解以及調(diào)優(yōu)內(nèi)容項(xiàng)，皆為原創(chuàng)........

第一個(gè)基礎(chǔ)模塊注重基礎(chǔ)內(nèi)容的掌握，共分7篇文章完成，內(nèi)容涵蓋一系列基礎(chǔ)運(yùn)算算法，詳細(xì)分析了如何查看執(zhí)行計(jì)劃、掌握執(zhí)行計(jì)劃優(yōu)化點(diǎn)，并一一列舉了日常我們平常所寫的T-SQL語句所會應(yīng)用的運(yùn)算符:

SQL Server調(diào)優(yōu)系列基礎(chǔ)篇

SQL Server調(diào)優(yōu)系列基礎(chǔ)篇（常用運(yùn)算符總結(jié)）

SQL Server調(diào)優(yōu)系列基礎(chǔ)篇（聯(lián)合運(yùn)算符總結(jié)）

SQL Server調(diào)優(yōu)系列基礎(chǔ)篇（并行運(yùn)算總結(jié)）

SQL Server調(diào)優(yōu)系列基礎(chǔ)篇（并行運(yùn)算總結(jié)篇二）

SQL Server調(diào)優(yōu)系列基礎(chǔ)篇（索引運(yùn)算總結(jié)）

SQL Server調(diào)優(yōu)系列基礎(chǔ)篇（子查詢運(yùn)算總結(jié)）

第二個(gè)進(jìn)階模塊注重SQL Server執(zhí)行T-SQL語句的時(shí)候一些內(nèi)幕解析，共分為5篇文章完成，其中包括：查詢優(yōu)化器的運(yùn)行方式、運(yùn)行時(shí)幾個(gè)優(yōu)化指標(biāo)值檢測，統(tǒng)計(jì)信息、利用索引等一系列內(nèi)容。通過這塊內(nèi)容讓我們了解SQL Server為我們所寫的T-SQL語句如何進(jìn)行優(yōu)化及運(yùn)行的。

SQL Server調(diào)優(yōu)系列進(jìn)階篇（查詢優(yōu)化器的運(yùn)行方式）

SQL Server調(diào)優(yōu)系列進(jìn)階篇（查詢語句運(yùn)行幾個(gè)指標(biāo)值監(jiān)測）

SQL Server調(diào)優(yōu)系列進(jìn)階篇（深入剖析統(tǒng)計(jì)信息）

SQL Server調(diào)優(yōu)系列進(jìn)階篇（如何索引調(diào)優(yōu)）

SQL Server調(diào)優(yōu)系列進(jìn)階篇（如何維護(hù)數(shù)據(jù)庫索引）

第三個(gè)玩轉(zhuǎn)模塊重點(diǎn)跟進(jìn)特定的問題進(jìn)行特定的提示（Hints)，基于前兩個(gè)模塊進(jìn)行的分析。

SQL Server調(diào)優(yōu)系列玩轉(zhuǎn)篇（如何利用查詢提示（Hint）引導(dǎo)語句運(yùn)行）

SQL Server調(diào)優(yōu)系列玩轉(zhuǎn)篇二（如何利用匯聚聯(lián)合提示（Hint）引導(dǎo)語句運(yùn)行）

如果您看了本篇博客,覺得對您有所收獲，請不要吝嗇您的“推薦”。