資源描述:
《sqlserver執(zhí)行計(jì)劃教會我如何創(chuàng)建索引?》由會員上傳分享,免費(fèi)在線閱讀,更多相關(guān)內(nèi)容在學(xué)術(shù)論文-天天文庫。
1、SQLServer執(zhí)行計(jì)劃教會我如何創(chuàng)建索引?SQLServer執(zhí)行計(jì)劃,是我們分析SQL執(zhí)行情況的一大利器,通過它,我們也可以很方面的查看索引的執(zhí)行,在實(shí)踐之前,需要了解一些必備技能,以下知識點(diǎn)摘自一看懂SqlServer查詢計(jì)劃。SQLServer有二種索引:聚集索引和非聚集索引。二者的差別在于:【聚集索引】直接決定了記錄的存放位置,或者說:根據(jù)聚集索引可以直接獲取到記錄?!痉蔷奂饕勘4媪硕€(gè)信息:1.相應(yīng)索引字段的值,2.記錄對應(yīng)聚集索引的位置(如果表沒有聚集索引則保存記錄指針)。因此如果能通過【聚集索引】來查找記錄,顯然也是最快的。SQLServ
2、er會有以下方法來查找您需要的數(shù)據(jù)記錄:【TableScan]:遍歷整個(gè)表,查找所有匹配的記錄行這個(gè)操作將會一行一行的檢查,當(dāng)然,效率也是最差的?!綢ndexScan】:根據(jù)索引,從表中過濾出來一部分記錄,再查找所有匹配的記錄行,顯然比第一種方式的查找范圍要小,因此比【TableScan】要快。【IndexSeek]:根據(jù)索引,定位(獲?。┯涗浀拇娣盼恢?,然后取得記錄,因此,比起前二種方式會更快?!綜lusteredlndexScan】:和【TableScan】一樣。注意:不要以為這里有個(gè)Index,就認(rèn)為不一樣了。其實(shí)它的意思是說:按聚集索引來逐行掃描每一
3、行記錄,因?yàn)橛涗浘褪前淳奂饕齺眄樞虼娣诺?。而【TableScan】只是說:要掃描的表沒有聚集索引而己,因此這二個(gè)操作本質(zhì)上也是一樣的?!綜lusteredlndexSeek]:直接根據(jù)聚集索引獲取記錄,最快!所以,當(dāng)發(fā)現(xiàn)某個(gè)查詢比較慢時(shí),可以首先檢查哪些操作的成本比較高,再看看那些操作在查找記錄時(shí),是不是[TableScan]或者【ClusteredlndexScan],如果確實(shí)和這二種操作類型有關(guān),則要考慮增加索引來解決了。不過,增加索引后,也會影響數(shù)據(jù)表的修改動作,因?yàn)樾薷臄?shù)據(jù)表時(shí),要更新相應(yīng)字段的索引。所以索引過多,也會影響性能。還有一種情況是不適合
4、增加索引的:某個(gè)字段用0或1表示的狀態(tài)。例如可能有絕大多數(shù)是1,那么此時(shí)加索引根本就沒有意義。這時(shí)只能考慮為0或者1這二種情況分開來保存了,分表或者分區(qū)都是不錯的選擇。應(yīng)用分析我們先不建任何索引(除了主鍵ID的聚集索引),來看一下上面SQL代碼,在SQLServer執(zhí)行計(jì)劃中的執(zhí)行情況:從上面的執(zhí)行計(jì)劃中,我們可以很直觀的看出差別,所以在寫SQL的時(shí)候,一定要慎重啊,這邊為了方便展示,我們還是以ProduceTime字段進(jìn)行排序,按照ID排序雖然沒有了SORT性能開銷,但是發(fā)現(xiàn)查詢記錄為“ClusteredlndexScan”,這是全表查詢的意思,我們理想的
5、應(yīng)該是“IndexSeek”或者“ClusteredlndexSeek”,因?yàn)檫@種是按照索引查詢,速度最快。按照我們程序員的理解,應(yīng)該創(chuàng)建一個(gè)非聚集索引,比如下面IX_Product_Provider_State索弓I:“IndexSeek”,這就是我們想要的效果,其實(shí)關(guān)于索引的創(chuàng)建有很多的現(xiàn)實(shí)問題,比如組合字段索引和單個(gè)字段索引有何不同?就像上面示例中的查詢用例,如果ProduceTime排序在其他查詢條件中也存在,是不是應(yīng)該拉出來創(chuàng)建一個(gè)索引?還是像上面一樣,和查詢條件一起創(chuàng)建一個(gè)組合字段索引?還有一種情況就是,在一個(gè)應(yīng)用程序查詢中,存在單個(gè)字段的查詢,
6、也存在組合字段的查詢,那這時(shí)候我們是創(chuàng)建單個(gè)字段索引?還是創(chuàng)建組合字段索引呢?這幾個(gè)問題,你創(chuàng)建一下索引,然后用“SQL執(zhí)行計(jì)劃”試試就知道了??偨Y(jié)針對上面的查詢用例,我個(gè)人覺得,最好的方案是:排序字段使用ID,按照實(shí)際應(yīng)用場景,提取出需要查詢的字段,避免SELECT*,這樣會減少在添加“包含性列”的字段,創(chuàng)建IX_Product_Provider_State非聚集索引,索引字段為:ProviderID和State,如果State的值不是多變的(比如值為1和0),盡量不要創(chuàng)建State字段的非聚集索引。做完這些,你會發(fā)現(xiàn),你的應(yīng)用程序像飛的一樣。