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

SQL Server非聚集索引概述

數(shù)據(jù)庫 SQL Server
我們今天是要和大家一起討論的是SQL Server非聚集索引(Noclustered Index Indications),我們是以假設(shè)例子的方式對其進行說明。

此文章主要向大家描述的是SQL Server非聚集索引(Noclustered Index Indications),在實際操作中SQL Server 2000數(shù)據(jù)庫可以允許你在一個表上最大程度的創(chuàng)建249個非聚集索引。直到表變得非常巨大,一個非聚集索引實際所占用的空間與日益增長的訪問性能相比是微不足道的。

然而,時刻牢記:隨著你在系統(tǒng)添加更多索引,數(shù)據(jù)修改語句由于索引性能的負(fù)擔(dān)會變得更慢。

當(dāng)定義SQL Server非聚集索引時,你也想在選擇性高的列上定義索引(也就是,具有低密度值的列)這樣它們能被優(yōu)化器來使用。一個非聚集索引中的大量重復(fù)值經(jīng)常使得使用非聚集索引比表掃描代價更高(按照I/O)。讓我們一起來看一個假設(shè)的例子:

  1. Sql代碼   
  2. Select title from titles   
  3. Where price between $5 and $10   
  4. Select title from titles  
  5. Where price between $5 and $10  

假設(shè)你在范圍內(nèi)有1,000,000行;這些1,000,000行隨機分散在整個表中。盡管索引葉級擁有全部的有序索引行,但在最壞情況下,一次讀一個數(shù)據(jù)行也將要求一個書簽查找。

這樣,在最壞情況下使用SQL Server非聚集索引來進行范圍檢索的I/O估計如下:

引用

非聚集索引的層數(shù)

+用于發(fā)現(xiàn)所有匹配行的掃描的索引頁數(shù)

+ 匹配的行數(shù) × 每個書簽查找的頁數(shù)

假如你的表上沒有聚集索引,那書簽僅僅是一個包括頁和行的指針,當(dāng)發(fā)現(xiàn)匹配的數(shù)據(jù)行時需要讀取一個數(shù)據(jù)頁。假如范圍內(nèi)有1,000,000行,當(dāng)該表沒有聚集索引時,借助非聚集索引的最壞情況的估計是:

引用

查找所有書簽需要讀取的索引頁數(shù)

+1,000,000匹配行 × 1數(shù)據(jù)頁的讀取

= 1,000,000 +I/Os

如果表中有聚集索引,書簽就是一個代表數(shù)據(jù)行的聚集索引鍵,用書簽來查找匹配的行要求搜索聚集索引樹來定位數(shù)據(jù)行。假設(shè)聚集索引有兩級非葉子節(jié)點,它將需要讀取三頁來在數(shù)據(jù)頁上查找每個滿足條件的行。如果范圍內(nèi)有1,000,000行,那么借助聚集索引的SQL Server非聚集索引來查找數(shù)據(jù),在最壞情況下它的代價估計如下:

引用

查找所有書簽所讀取的索引頁的個數(shù)

+1,000,000匹配的行 * 每個書簽查找需求的3頁

=3,000,00+I/Os

把每種情況與表掃描相對比。如果整個表占用了50,000頁,那么一個全表掃描將只花費50,000 I/O。所以,在這個例子中,一個表掃描實際將比用非聚集索引更有效。

下面的指南幫助你識別非聚集索引的潛在的候選者。

SARG或join子句中引用的相對來說具有較高的選擇性(密度值低)的列。

Where子句和order by子句都引用的列。

當(dāng)使用非聚集索引來檢索數(shù)據(jù)行時,它們按照非聚集索引鍵的順序被檢索出來。如果結(jié)果集也需要按照SQL Server非聚集索引進行排序,SQL Server能避免對結(jié)果集重新排序,這樣可實現(xiàn)一個更有效的查詢。下面就是這樣一個例子:

  1. Sql代碼   
  2. Select * from authors   
  3. Where state like "c%"   
  4. Order by state   
  5. Select * from authors  
  6. Where state like "c%"  
  7. Order by state  

一般情況下,非聚集索引對單行查找(single-row lookup),連接(join),有高選擇性的列的查詢,小范圍檢索的查詢有用。當(dāng)你考慮非聚集索引的設(shè)計時也不要忽略了覆蓋索引的優(yōu)點,下節(jié)將會講到。

索引覆蓋(Index Covering)

索引覆蓋是這樣一種情況,查詢中的select 和where子句中所需要的信息都能在非聚集索引中找到。因為非聚集索引包含了一個對應(yīng)于表中每個數(shù)據(jù)行的一個葉子行,SQL Server能從非聚集索引的葉子行來滿足查詢。這導(dǎo)致了數(shù)據(jù)檢索的更快,因為所有的信息能從索引頁中直接獲得,并且避免了SQL Server查找數(shù)據(jù)頁。

因為非聚集索引的葉子頁都連接在一起,索引的葉級可以像表中的數(shù)據(jù)頁一樣進行掃描,因為頁級行都典型比數(shù)據(jù)行要小,一個覆蓋了查詢的非聚集索引將比同樣列的聚集索引更快,因為需要讀取的頁數(shù)要更少。

在下面的例子中,quthors表中的關(guān)于au_lname 和au_fname的SQL Server非聚集索引將覆蓋查詢,因為結(jié)果中的列和SARG都能從索引中提取出來:

  1. Sql代碼   
  2. Select au_lname, au_fname   
  3. From authors   
  4. Where au_lname like "M%"   
  5. GO   
  6. Select au_lname, au_fname  
  7. From authors  
  8. Where au_lname like "M%"  
  9. GO  

其他使用聚合函數(shù)(MIN AVG SUM COUNT)的查詢或者僅僅檢查是否存在的查詢也能從索引覆蓋中獲益。下面是一些能夠利用索引覆蓋優(yōu)點的查詢:

  1. Sql代碼   
  2. Select count (au_lname) from authors where au_lname like 'm%'   
  3. Select count (*) from authors where au_lname like 'm%'   
  4. Select count (*) from authors   
  5. Select count (au_lname) from authors where au_lname like 'm%'  
  6. Select count (*) from authors where au_lname like 'm%'  
  7. Select count (*) from authors  

你可能會奇怪最后一個查詢,它甚至沒有一個具體的SARG,怎么還能使用索引。SQL Server知道非聚集索引的特性,一個非聚集索引為表中的每行數(shù)據(jù)都包含了一行;它能夠簡單的計算任何一個非聚集索引的行數(shù),而不需要掃描整個表。對最后一個查詢,SQL Server選擇最小的SQL Server非聚集索引——也就是,具有最少的葉子頁的索引。

向非聚集索引添加列使得發(fā)生索引覆蓋是一種提高查詢響應(yīng)時間的常見方法。考慮下面的查詢:

  1. Sql代碼   
  2. Select royalty from titles   
  3. Where price between $10 and $ 20   
  4. Select royalty from titles  
  5. Where price between $10 and $ 20  
  6.  

如果你僅在price列上創(chuàng)建索引,SQL Server能發(fā)現(xiàn)滿足price在該范圍的索引中的行,但是它還需要訪問數(shù)據(jù)行來檢索royalty。范圍中有100行,最壞情況下檢索數(shù)據(jù)所花費的IO代價計算如下:

引用

索引的級數(shù)

+查找匹配行的索引頁的數(shù)

+100 * 每個書簽查找頁數(shù)

如果royalty列添加到了price列索引中了,索引能被掃描來檢索結(jié)果,而不是進行書簽查找,這樣具有更快的查詢響應(yīng)。使用索引覆蓋的IO代價將只是:

引用

索引級數(shù)

+查找匹配行的索引頁的數(shù)

引用

注意:

當(dāng)考慮添加索引來利用索引覆蓋時,小心使得索引變得太寬。當(dāng)索引行的寬度接近與數(shù)據(jù)行寬度時,覆蓋的優(yōu)點將失去,因為增加了葉級頁的數(shù)目。當(dāng)索引的葉級頁的數(shù)目接近了表中頁的數(shù)目,索引級數(shù)也增加了,那么索引掃描的時間就開始接近于表掃描時間了。

另外,如果你添加對到索引中的列頻繁修改,數(shù)據(jù)行中列的任何修改也會波及到索引中。這增加了維護的負(fù)擔(dān),也會影響修改的性能。

正如第33章討論的那樣,當(dāng)在一個表上創(chuàng)建了 一個聚集索引,聚集鍵會被所有的SQL Server非聚集索引引用,作為書簽來定位實際的數(shù)據(jù)行。聚集鍵實際就是一些列,它們構(gòu)成了聚集索引和它們的數(shù)據(jù)值。這種特性有時也能導(dǎo)致索引覆蓋。

例如,假設(shè)suthors表在au_lname au_fname列上建立聚集索引,并有一個定義在au_id的非聚集索引。非聚集索引的每行都包含了與數(shù)據(jù)行對應(yīng)的au_lname au_fname聚集鍵值。因為這個原因,下面查詢將被非聚集索引覆蓋:

  1. Sql代碼   
  2. select au_lname, au_fname   
  3. from authors   
  4. where au_id like '123%'   
  5. select au_lname, au_fname   
  6. from authors  
  7. where au_id like '123%'  

以上的相關(guān)內(nèi)容就是對SQL Server非聚集索引(Noclustered Index Indications)的介紹,望你能有所收獲。

【編輯推薦】

  1. SQL Server數(shù)據(jù)庫在安裝時的注意事項
  2. SQL Server 2005數(shù)據(jù)庫安裝實例演示
  3. SQL Server數(shù)據(jù)庫與identity列
  4. SQL Server 實用操作的代碼演示
  5. SQL Server數(shù)據(jù)庫與max degree of parallelism參數(shù)
責(zé)任編輯:佚名 來源: 博客園
相關(guān)推薦

2014-08-28 10:06:57

SQL Server

2010-07-20 12:46:23

SQL Server聚

2011-04-22 14:45:45

SQL索引

2010-07-07 11:20:02

SQL Server聚

2022-11-28 07:25:52

MySQL聚集索引

2010-07-20 13:20:26

SQL Server聚

2010-07-19 16:17:41

SQL Server聚

2011-03-30 11:28:31

SQL Server聚集索引

2010-07-07 10:47:58

SQL Server索

2010-07-19 14:31:14

SQL Server

2013-07-12 09:26:12

SQL ServerSQL PASS微軟MVP

2015-10-30 15:55:43

MySQL

2010-07-26 11:27:43

SQL Server打

2010-07-06 11:36:16

SQL Server集

2023-06-05 08:07:34

聚集索引存儲數(shù)據(jù)

2010-07-07 13:58:25

SQL Server死

2010-06-17 10:43:21

SQL Server

2010-09-16 13:42:55

SQL SERVER索

2010-07-07 10:54:22

SQL Server索

2010-07-14 15:04:53

SQL Sever索引
點贊
收藏

51CTO技術(shù)棧公眾號

主站蜘蛛池模板: 久久综合久 | 91久久伊人| 人人澡人人爱 | 在线观看免费av网站 | aaaaaaa片毛片免费观看 | 麻豆av片 | 欧美精品在线播放 | 色999视频| 久久久妇女国产精品影视 | 国产精品久久在线 | 国产91中文 | 久久精品欧美一区二区三区不卡 | 国产在线一区二区三区 | 91高清视频在线观看 | 黄色一级大片视频 | 国产精品久久久久久久久久 | 欧美激情五月 | 亚洲三区在线 | 国产精品久久久久久中文字 | 亚洲一区二区三区免费 | 超碰在线播 | 亚洲国产精品精华素 | 日本不卡高字幕在线2019 | 日韩插插 | 日韩一二区| 精品在线一区 | 亚洲欧美国产毛片在线 | 亚洲成人一级 | 911影院 | 久久69精品久久久久久久电影好 | 国产一区二区三区 | 国产精品欧美一区喷水 | 久久综合久久久 | 天堂一区二区三区 | 嫩呦国产一区二区三区av | 欧美日韩激情 | 亚洲网站在线播放 | 色久影院 | 99精品在线 | 日韩欧美在线不卡 | 综合色婷婷|