日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

此文章主要向大家探討的是SQL Server索引的具體使用標準（Index Usage Criteria），在實際操作中我們大家為了其更為有效的決定創(chuàng)建哪些合適的SQL Server數(shù)據(jù)庫索引，你必須決定這些索引實際中是否被SQL Server使用過。

創(chuàng)新互聯(lián)建站專注于藍山企業(yè)網站建設,響應式網站開發(fā),電子商務商城網站建設。藍山網站建設公司,為藍山等地區(qū)提供建站服務。全流程按需定制開發(fā)，專業(yè)設計，全程項目跟蹤，創(chuàng)新互聯(lián)建站專業(yè)和態(tài)度為您提供的服務

如果一個索引不能被有效使用，在修改數(shù)據(jù)時，那只會浪費空間和增加不必要的負擔。

需要記住的主要標準是：如果至少是SQL Server索引的***列沒有被包含在一個有效的搜索參數(shù)（search argument SARG）或join子句中，那么SQL Server 就不會使用索引進行更有效地書簽查找（bookmark lookup）。為創(chuàng)建復合索引，選擇列的順序時牢記住這一點，想想下面的在store表中的索引：

Create index nc1_stores on stores (city, state, zip)

下面的每一個查詢將會用到索引，因為它們包含了SQL Server索引的***列city，其為一個SARG：

Sql代碼

 
 
 

  
  
  
select stor_name from stores   
  
  
  
where city = 'Frederick'   
  
  
  
and state = 'MD'   
  
  
  
and zip = '21702'   
  
  
  
select stor_name from stores   
  
  
  
where city = 'Frederick' 
  
  
  
and state = 'MD' 
  
  
  
and zip = '21702' 
  
  
  
Sql代碼   
  
  
  
select stor_name from stores   
  
  
  
where city = 'Frederick'   
  
  
  
and state = 'MD'   
  
  
  
select stor_name from stores  
  
  
  
where city = 'Frederick' 
  
  
  
and state = 'MD' 
  
  
  
Sql代碼   
  
  
  
select stor_name from stores   
  
  
  
where city = 'Frederick'   
  
  
  
and zip = '21702'   
  
  
  
select stor_name from stores  
  
  
  
where city = 'Frederick' 
  
  
  
and zip = '21702' 
 
 
 

然而，下面的查詢不會用到SQL Server索引而進行書簽查找，因為它們沒指定city列為一個SARG：

 
 
 

  
  
  
Sql代碼   
  
  
  
select stor_name from stores   
  
  
  
where state = 'MD'   
  
  
  
and zip = '21702'   
  
  
  
select stor_name from stores   
  
  
  
where state = 'MD' 
  
  
  
and zip = '21702' 
  
  
  
Sql代碼   
  
  
  
select stor_name from stores   
  
  
  
where zip = '21702'   
  
  
  
select stor_name from stores  
  
  
  
where zip = '21702' 
  
  
  
 
 
 
 

引用

注釋：

對于前面提到的***兩個查詢，如果你顯示執(zhí)行計劃（execution plan）信息，你可能發(fā)現(xiàn)，查詢實際上使用了nc1_store索引來檢索了結果集（resultset）。如果再仔細看，你會發(fā)現(xiàn)查詢沒有使用索引最有效地方式——它使用了索引掃描（index scan），而不是索引查找（index seek）。

有關查詢存取方法（query aceess method）的更多信息，可參見第35章“Understanding Query Optimization”，在該章中將講述索引查找。

在索引查找（Index seek）中，SQL Server 沿著索引樹（index tree）從根級（root level）向下進行索引鍵值匹配搜索，直到搜索到指定的行，然后使用存儲在索引鍵值中的書簽值（bookmark value）直接從數(shù)據(jù)頁中檢索匹配的數(shù)據(jù)行(這個書簽值可以是行標識符（RID），或者聚集索引的鍵值)。

對一個索引掃描（Index scan），SQL Server搜索索引樹中所有葉級（leaf level）中的行來進行可能匹配的查找。如果發(fā)現(xiàn)滿足匹配的行，然后利用書簽檢索數(shù)據(jù)行。

盡管兩者都使用了索引，從I/O代價角度來講，索引掃描比SQL Server索引查找的代價要高，但比表掃描（Table scan)要略微要小些。然而，本章學習設計索引的目的是為了使用索引查找，所以當我談到使用索引時，指的是索引查找。

為了得到可能列的書簽查詢，你可能想到的一個容易的方法是在表中所有列上都創(chuàng)建索引，這樣任何類型的查詢都可以使用索引了。這種策略可能在某些支持ad hoc queries（隨意的查詢）的只讀的DSS（決策支持系統(tǒng)）環(huán)境下是合適的，但是這樣也存在問題，因為仍然會造成有許多索引不被使用。

正如你在本章的Index selection節(jié)看到的，不會僅僅因為在某列創(chuàng)建了索引，優(yōu)化器就總會使用該列的索引，例如，當該列的選擇性不夠時（not selective enough），就不會使用該列的索引。另外，在一張大表（large table）上創(chuàng)建太多索引會占據(jù)數(shù)據(jù)庫中的大量空間，增加了備份的要求時間。前面也提到過，在一個OLTP（在線聯(lián)機處理）系統(tǒng)上，太多的索引會給數(shù)據(jù)的插入、修改、刪除操作帶來大量的額外負擔，造成性能上的不利影響。

引用

建議：（每張表4-5個索引）

我曾經常犯的一個設計錯誤是在OLTP環(huán)境下定義了太多的索引。許多情況下，有些索引是冗余的或者是優(yōu)化器在處理查詢時就根本沒有考慮。結果，這些索引導致空間的浪費和增加了修改數(shù)據(jù)時的不必要負擔。

在這一點上有一個案例，有個客戶在一個表上創(chuàng)建了8個索引，其中4個索引都是在同一列上，該列的鍵值唯一（unique key），在索引中該列都是***個索引列。對表的查詢和修改操作，該列都包含在where 子句中。結果只有4個的其中1個SQL Server索引曾被用到過。

希望在本章結束后，你將會理解為什么所有這些索引不是必須的，并且能重新認識和決定在哪些列上創(chuàng)建索引將會收益，而哪些列上應避免創(chuàng)建索引。

網頁題目：SQLServer索引如何使用時正確的？
地址分享：http://www.5511xx.com/article/coeessj.html