成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

解析索引中數據列順序的選擇問題

數據庫 SQL Server
在多個列上面建立索引的時候,我們常常會遇到這樣的一個問題“需要把哪個列放在前面”,因為索引中列順序的不同,會對索引的使用,以至性能產生很大的影響。我們本篇就來分析這個問題。

在多個列上面建立索引的時候,我們常常會遇到這樣的一個問題“需要把哪個列放在前面”,因為索引中列順序的不同,會對索引的使用,以至性能產生很大的影響。我們本篇就來分析這個問題。

對于上面的問題,一個常見的回答就是“把選擇性***列放在前面”,這里為了使得后面的講述順序進行,我們先來解釋一下選擇性的含義。選擇性是用來描述數據的差異情況的,例如,如果一個表中有1000條數據,其中的某個字段,如ID,如果每一條數據的ID值都不一樣,那么ID的選擇性就是1;如果其中有300百個ID是一樣的,那么就是說,有700個ID不同,那么選擇性就是70%。很顯然,數據的選擇性越高,那么在上面建立索引效果就越好。

下面,我們就來解釋一下為什么在多個列上面建立索引的時候需要把選擇性高的列放在最前面。

也許有朋友聽到上面的建議之后,在建立任何基于多個列的索引的時候,都會把表的聚集索引所在的列作為這個多列索引的***個字段。例如,假設現在表中有4個字段,ID,Name,Age,BirthDate,其中ID是主鍵,也是聚集索引,現在我們需要在Name,BirthDate上面建立索引,這個時候,有朋友發現:ID的選擇性***,那么把ID放在新的索引中,勢必會更好,于是一個名字為IX_Index的索引就包含了三個列:ID,Name,BirthDate。到后來,可能就發現,如果冒冒然的這樣做,使得這個新建的索引沒有發揮作用,反而導致性能問題。

對于數據庫中的每一個索引,都會有相應的統計數據信息,這個統計數據顯示了數據的分布情況,統計信息以一個類似柱形的形式表現了數據的分布。數據庫只把索引中的***個列的數據分布情況放在柱形圖中,換句話說,這個統計信息顯示的就是索引中的***個數據列的數據分布情況(這里面涉及到的內容有點深,大家可以關注本站點的“查詢優化器內核系列”,里面會講述到)。

我給大家看個例子吧,假設在SalesOrderDetail表上面有一個索引:X_SalesOrderDetail_ProductID,運行下面的語句:

20120412182749.png

這個索引包含的列有:ProductID,SalesOrderID和SalesOrderDetailID。我們查看它的數據的柱形分布圖,如下:

20120412182822.png

我們發現,其中的RANGE_HI_KEY列出的就是ProductID的值,通過圖中,我們可以知道:ProductID值為826的數據有305條,值為831的數據有198條。ProductID的值在826到831之間的數據有110條。查詢優化器就是根據這個來估算數據的條數的。

通過上面可以知道:把索引中的哪個列放在前面至關重要,如果把一個選擇性很低的列放在前面,那么就導致索引的統計數據顯示的數據分布完全改變,可能導致查詢優化器選擇比較低效的執行計劃。

下面,我們就通過一個例子來進一步的看看這個問題。

首先,建立一個測試的表,如下:

20120412182855.png

這個表中有10000條數據,并且這個表是一個堆表,即沒有聚集索引的表。并且在這個表中有100個不同的SomeString值,有5000個不同的SomeDate值,而ID是唯一的,全部都不同。

那么,上面的值的選擇性如下:

字段名

選擇性

ID

100%

SomeString

100/10000*100%=1%

SomeDate

5000/10000*100%=50%

在表中,有一個非聚集索引,假設名字為Idx_test,包含了表中的三個值,三個列在索引中的順序為:ID,SomeDate,SomeString,按照選擇性排序,確實不錯! 

  1. …  WHERE ID = @ID AND SomeDate = @dt AND SomeString = @str  
  2. …  WHERE ID = @ID AND SomeDate = @dt  
  3. …  WHERE ID = @ID 

 

換句話說,就是這個索引只在查詢中的Where/Join的列按照索引中的列的順序使用的時候才有效。如果查詢是這樣的,如下:

對于上面的索引,只有在類似下面的查詢結構中發揮作用,如下:

  1. …  WHERE SomeDate = @dt或者…  SomeDate = @dt AND SomeString = @str 

那么,這個索引就不會上面的查詢中使用了,那么查詢在執行的時候就會掃描整表了。

我們通過執行計劃來看看是不是這樣的。

 

對于,WHERE ID = @ID的查詢,執行計劃如下:

 

20120412183136.png

很顯然,執行了Seek操作,是很快的。

 

對于WHERE ID = @ID AND SomeDate = @dt的查詢,執行計劃如下:

20120412183207.png

還是進行了Seek操作。

那么對于… SomeDate = @dt AND SomeString = @str的查詢,如下:

 

20120412183301.png

大家可以看到,這個時候已經開始進行全表掃描了。

 

我們本篇講述了在索引的進行列的相等操作時候,列的順序問題,我們下一篇就講述如果是在列上進行不等操作,例如ID>1,那么索引中的列的順序還是這樣進行嗎?

 

原文鏈接:http://www.cnblogs.com/yanyangtian/archive/2012/05/03/2480052.html

【編輯推薦】

  1. 我們該如何設計數據庫
  2. 點評:巍然聳立的SQL Server 2012
  3. SQL Server 2008中增強的匯總技巧
責任編輯:林師授 來源: 燕洋天的博客
相關推薦

2023-05-05 10:45:39

聯合索引數據

2010-05-26 13:42:08

MySQL數據庫索引

2011-03-23 15:57:43

Oracle索引

2010-03-30 17:40:59

Oracle數據庫

2010-10-27 13:35:15

Oracle查詢

2012-09-26 10:42:11

大數據

2011-07-25 16:13:34

SQL Server數據挖掘

2021-10-12 07:58:10

MySQL索引數據

2017-08-02 14:02:42

MysqlMysql優化Mysql索引

2024-11-11 13:28:11

RocketMQ消息類型FIFO

2010-06-25 15:03:54

路由選擇協議

2010-07-07 10:12:44

SQL Server

2010-11-23 13:29:36

MySQL數據列類型

2023-03-05 20:28:49

數據數據集架構

2011-02-22 14:10:25

PHPXML

2010-05-11 18:14:52

Mysql數據庫編碼

2019-11-06 09:30:35

SQL查詢語句數據庫

2009-12-11 10:41:11

PHP變量解析順序

2012-02-14 13:39:57

Java

2010-07-07 10:31:43

SQL Server數
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 欧美成年网站 | 亚洲黄色一级毛片 | 国产精品久久精品 | 91久久久久久久久久久 | 在线国产视频 | 91一区| 日韩精品在线看 | 国产一区二区中文字幕 | 亚洲欧美一区二区三区在线 | 9久久精品 | 国产美女一区二区 | a视频在线观看 | 中文字幕av一区 | 国产日韩欧美一区二区 | 国产一区二区三区www | 中文字幕在线精品 | 亚洲精品一区中文字幕乱码 | 免费黄色的视频 | 欧美日韩在线视频一区 | 亚洲一区毛片 | 91麻豆精品国产91久久久更新资源速度超快 | 国产探花在线精品一区二区 | 久久91精品| 香蕉av免费 | 日韩在线精品视频 | 久久久123| 欧美激情网站 | 激情视频中文字幕 | 国产一级片网站 | 国产在线视频一区二区董小宛性色 | 国产精品久久99 | 久久成人精品一区二区三区 | 国产精品99一区二区 | 亚洲一区在线日韩在线深爱 | 在线观看亚洲专区 | 色综合久久久 | 久久久久久黄 | 欧美男人天堂 | 99视频久| 中文字幕乱码一区二区三区 | 日韩成人在线观看 |