索引sqlserver

Ⅰ sqlServer：索引是什麼，以及為什麼使用索引

收藏
問題反饋
索引
索引，使用索引可快速訪問資料庫表中的特定信息。索引是對資料庫表中一列或多列的值進行排序的一種結構。 在關系資料庫中，索引是一種與表有關的資料庫結構，它可以使對應於表的SQL語句執行得更快。索引的作用相當於圖書的目錄，可以根據目錄中的頁碼快速找到所需的內容。當表中有大量記錄時，若要對表進行查詢，第一種搜索信息方式是全表搜索，是將所有記錄一一取出，和查詢條件進行一一對比，然後返回滿足條件的記錄，這樣做會消耗大量資料庫系統時間，並造成大量磁碟I/O操作；第二種就是在表中建立索引，然後在索引中找到符合查詢條件的索引值，最後通過保存在索引中的ROWID（相當於頁碼）快速找到表中對應的記錄。 索引是一個單獨的、物理的資料庫結構，它是某個表中一列或若干列值的集合和相應的指向表中物理標識這些值的數據頁的邏輯指針清單。 索引提供指向存儲在表的指定列中的數據值的指針，然後根據您指定的排序順序對這些指針排序。資料庫使用索引的方式與您使用書籍中的索引的方式很相似：它搜索索引以找到特定值，然後順指針找到包含該值的行。 在資料庫關系圖中，可以在選定表的「索引/鍵」屬性頁中創建、編輯或刪除每個索引類型。當保存索引所附加到的表，或保存該表所在的關系圖時，索引將保存在資料庫中。

Ⅱ 如何利用索引提高SQLServer數據處理的效率

在良好的資料庫設計基礎上，能有效地使用索引是SQL Server取得高性能的基礎，SQL Server採用基於代價的優化模型，它對每一個提交的有關表的查詢，決定是否使用索引或用哪一個索引。因為查詢執行的大部分開銷是磁碟I/O，使用索引提高性能的一個主要目標是避免全表掃描，因為全表掃描需要從磁碟上讀表的每一個數據頁，如果有索引指向數據值，則查詢只需讀幾次磁碟就可以了。
所以如果建立了合理的索引，優化器就能利用索引加速數據的查詢過程。但是，索引並不總是提高系統的性能，在增、刪、改操作中索引的存在會增加一定的工作量，因此，在適當的地方增加適當的索引並從不合理的地方刪除次優的索引，將有助於優化那些性能較差的SQL Server應用。實踐表明，合理的索引設計是建立在對各種查詢的分析和預測上的，只有正確地使索引與程序結合起來,才能產生最佳的優化方案。本文就SQL Server索引的性能問題進行了一些分析和實踐。
一、聚簇索引(clustered indexes)的使用
聚簇索引是一種對磁碟上實際數據重新組織以按指定的一個或多個列的值排序。由於聚簇索引的索引頁面指針指向數據頁面，所以使用聚簇索引查找數據幾乎總是比使用非聚簇索引快。每張表只能建一個聚簇索引，並且建聚簇索引需要至少相當該表120%的附加空間，以存放該表的副本和索引中間頁。建立聚簇索引的思想是：
1、大多數表都應該有聚簇索引或使用分區來降低對表尾頁的競爭，在一個高事務的環境中，對最後一頁的封鎖嚴重影響系統的吞吐量。
2、在聚簇索引下，數據在物理上按順序排在數據頁上，重復值也排在一起，因而在那些包含范圍檢查(between、<、<=、>、>=)或使用group by或order by的查詢時，一旦找到具有范圍中第一個鍵值的行，具有後續索引值的行保證物理上毗連在一起而不必進一步搜索，避免了大范圍掃描，可以大大提高查詢速度。
3、在一個頻繁發生插入操作的表上建立聚簇索引時，不要建在具有單調上升值的列(如IDENTITY)上，否則會經常引起封鎖沖突。
4、在聚簇索引中不要包含經常修改的列，因為碼值修改後，數據行必須移動到新的位置。
5、選擇聚簇索引應基於where子句和連接操作的類型。
聚簇索引的侯選列是：
1、主鍵列,該列在where子句中使用並且插入是隨機的。
2、按范圍存取的列，如pri_order > 100 and pri_order < 200。
3、在group by或order by中使用的列。
4、不經常修改的列。
5、在連接操作中使用的列。
二、非聚簇索引(nonclustered indexes)的使用
SQL Server預設情況下建立的索引是非聚簇索引，由於非聚簇索引不重新組織表中的數據，而是對每一行存儲索引列值並用一個指針指向數據所在的頁面。換句話說非聚簇索引具有在索引結構和數據本身之間的一個額外級。一個表如果沒有聚簇索引時,可有250個非聚簇索引。每個非聚簇索引提供訪問數據的不同排序順序。在建立非聚簇索引時，要權衡索引對查詢速度的加快與降低修改速度之間的利弊。另外，還要考慮這些問題：
1、索引需要使用多少空間。
2、合適的列是否穩定。
3、索引鍵是如何選擇的，掃描效果是否更佳。
4、是否有許多重復值。
對更新頻繁的表來說，表上的非聚簇索引比聚簇索引和根本沒有索引需要更多的額外開銷。對移到新頁的每一行而言，指向該數據的每個非聚簇索引的頁級行也必須更新，有時可能還需要索引頁的分理。從一個頁面刪除數據的進程也會有類似的開銷，另外，刪除進程還必須把數據移到頁面上部，以保證數據的連續性。所以，建立非聚簇索引要非常慎重。非聚簇索引常被用在以下情況：
1、某列常用於集合函數(如Sum,....)。
2、某列常用於join,order by,group by。
3、查尋出的數據不超過表中數據量的20%。
三、覆蓋索引(covering indexes)的使用
覆蓋索引是指那些索引項中包含查尋所需要的全部信息的非聚簇索引，這種索引之所以比較快也正是因為索引頁中包含了查尋所必須的數據,不需去訪問數據頁。如果非聚簇索引中包含結果數據,那麼它的查詢速度將快於聚簇索引。
但是由於覆蓋索引的索引項比較多,要佔用比較大的空間。而且update操作會引起索引值改變。所以如果潛在的覆蓋查詢並不常用或不太關鍵，則覆蓋索引的增加反而會降低性能。
四、索引的選擇技術
p_detail是住房公積金管理系統中記錄個人明細的表，有890000行，觀察在不同索引下的查詢運行效果，測試在C/S環境下進行，客戶機是IBM PII350(內存64M),伺服器是DEC Alpha1000A(內存128M),資料庫為SYBASE11.0.3。
1、 select count(*) from p_detail where
op_date>』19990101』 and op_date<』
19991231』 and pri_surplus1>300
2、 select count(*),sum(pri_surplus1) from p_detail
where op_date>』19990101』 and
pay_month between『199908』 and』199912』
不建任何索引查詢1 1分15秒
查詢2 1分7秒
在op_date上建非聚簇索引查詢1 57秒
查詢2 57秒
在op_date上建聚簇索引查詢1 <1秒
查詢2 52秒
在pay_month、op_date、pri_surplus1上建索引查詢1 34秒
查詢2 <1秒
在op_date、pay_month、pri_surplus1上建索引查詢1 <1秒
查詢2 <1秒
從以上查詢效果分析，索引的有無，建立方式的不同將會導致不同的查詢效果，選擇什麼樣的索引基於用戶對數據的查詢條件,這些條件體現於where從句和join表達式中。一般來說建立索引的思路是：
(1)主鍵時常作為where子句的條件，應在表的主鍵列上建立聚簇索引，尤其當經常用它作為連接的時候。
(2)有大量重復值且經常有范圍查詢和排序、分組發生的列，或者非常頻繁地被訪問的列，可考慮建立聚簇索引。
(3)經常同時存取多列，且每列都含有重復值可考慮建立復合索引來覆蓋一個或一組查詢，並把查詢引用最頻繁的列作為前導列，如果可能盡量使關鍵查詢形成覆蓋查詢。
(4)如果知道索引鍵的所有值都是唯一的，那麼確保把索引定義成唯一索引。
(5)在一個經常做插入操作的表上建索引時，使用fillfactor(填充因子)來減少頁分裂，同時提高並發度降低死鎖的發生。如果在只讀表上建索引，則可以把fillfactor置為100。
(6)在選擇索引鍵時，設法選擇那些採用小數據類型的列作為鍵以使每個索引頁能夠容納盡可能多的索引鍵和指針，通過這種方式，可使一個查詢必須遍歷的索引頁面降到最小。此外，盡可能地使用整數為鍵值，因為它能夠提供比任何數據類型都快的訪問速度。
五、索引的維護
上面講到,某些不合適的索引影響到SQL Server的性能,隨著應用系統的運行,數據不斷地發生變化,當數據變化達到某一個程度時將會影響到索引的使用。這時需要用戶自己來維護索引。索引的維護包括：
1、重建索引
隨著數據行的插入、刪除和數據頁的分裂，有些索引頁可能只包含幾頁數據，另外應用在執行大塊I/O的時候，重建非聚簇索引可以降低分片，維護大塊I/O的效率。重建索引實際上是重新組織B-樹空間。在下面情況下需要重建索引：
(1)數據和使用模式大幅度變化。
(2)排序的順序發生改變。
(3)要進行大量插入操作或已經完成。
(4)使用大塊I/O的查詢的磁碟讀次數比預料的要多。
(5)由於大量數據修改，使得數據頁和索引頁沒有充分使用而導致空間的使用超出估算。
(6)dbcc檢查出索引有問題。
當重建聚簇索引時，這張表的所有非聚簇索引將被重建。
2、索引統計信息的更新
當在一個包含數據的表上創建索引的時候，SQL Server會創建分布數據頁來存放有關索引的兩種統計信息：分布表和密度表。優化器利用這個頁來判斷該索引對某個特定查詢是否有用。但這個統計信息並不動態地重新計算。這意味著，當表的數據改變之後，統計信息有可能是過時的，從而影響優化器追求最有工作的目標。因此，在下面情況下應該運行update statistics命令：
(1)數據行的插入和刪除修改了數據的分布。
(2)對用truncate table刪除數據的表上增加數據行。
(3)修改索引列的值。
六、結束語
實踐表明，不恰當的索引不但於事無補，反而會降低系統的執行性能。因為大量的索引在插入、修改和刪除操作時比沒有索引花費更多的系統時間。例如下面情況下建立的索引是不恰當的：
1、在查詢中很少或從不引用的列不會受益於索引，因為索引很少或從來不必搜索基於這些列的行。
2、只有兩個或三個值的列，如男性和女性(是或否)，從不會從索引中得到好處。
另外，鑒於索引加快了查詢速度，但減慢了數據更新速度的特點。可通過在一個段上建表，而在另一個段上建其非聚簇索引，而這兩段分別在單獨的物理設備上來改善操作性能。

Ⅲ sqlserver怎麼為表添加索引怎麼用

可以用create index創建索引,如create index test_idx on tablename(col1,col2)
系統優化時會自動選擇使整個查詢開銷最小的查詢計劃。如你的sql 為select * from tablename where col1 = @col1 and col2 = @col2 時一般都會用到索引。

Ⅳ SQLSERVER對索引的利用及非SARG運算符認識

寫SQL語句的時候很多時候會用到filter篩選掉一些記錄，SQL對篩選條件簡稱：SARG（search
argument/SARG）
復制代碼
代碼如下:
where
amount>4000
and
amount<6000上面這句就是篩選條件
當然這里不是說SQLSERVER的where子句，是說SQLSERVER對索引的利用在SQLSERVER對於沒有SARG運算符的表達式，索引是沒有用的，SQLSERVER對它們很難使用比較優化的做法。
意思是說，如果你的SQL語句中沒有where子句包括非SARG運算符，那麼你的SQL語句是不會用到表格中的索引的
下面說一下哪些是非SARG運算符：
非SARG運算符包括
NOT、
<>、
NOT
EXISTS、
NOT
IN、
NOT
LIKE
規律就是有「NOT」
關鍵字
或者
不等於的意思
基本上利用不了索引
還有一些內部函數，如果使用這些內部函數SQLSERVER也不會用到索引
內部函數，例如：CONVERT()，UPPER()等

Ⅳ sqlserver 怎麼建索引

CREATE INDEX
為給定表或視圖創建索引。

只有表或視圖的所有者才能為表創建索引。表或視圖的所有者可以隨時創建索引，無論表中是否有數據。可以通過指定限定的資料庫名稱，為另一個資料庫中的表或視圖創建索引。

語法
CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX index_name
ON { table | view } ( column [ ASC | DESC ] [ ,...n ] )
[ WITH < index_option > [ ,...n] ]
[ ON filegroup ]

< index_option > ::=
{ PAD_INDEX |
FILLFACTOR = fillfactor |
IGNORE_DUP_KEY |
DROP_EXISTING |
STATISTICS_NORECOMPUTE |
SORT_IN_TEMPDB
}
--這是基本語法，建立索引，只針對查詢和一些更新和刪除的速度，像性別一列，如果表裡面有1000行，如果只有1行是男，這樣用索引的話肯定高，如果有990行是男，那麼它不如直接掃描了，這是選擇性

Ⅵ sqlserver怎麼建立索引

--創建索引
CREATE NONCLUSTERED INDEX IX_TEST_TNAME --創建一個非聚集索引
ON TEST(TNAME) --為TEST表的TNAME欄位創建索引
WITH FILLFACTOR = 30 --填充因子為30%
GO
SELECT * FROM TEST(INDEX = IX_TEST_TNAME) WHERE TNAME = 'A' --指定按『IX_TE

Ⅶ 如何查表是否有索引 sqlserver

1、本文以表pi_content為例，相應的欄位為（[piid] int, [seqnum] int,[phname] nvarchar(50),[content] nvarchar(MAX)），數據量為百萬級。

Ⅷ 為什麼說SQLServer全文索引有局限性

下面假設有這樣一個例子：在DataBase_name。dbo。Table_name中有一個名為Title(標題)和Contents(內容)的欄位，現在需要查詢在Title或者Contents中包括「qq」字元的所有記錄。 面對這樣的一個場景，我們通常都會寫這樣一個腳本：SELECT * FROM DataBase_name。
dbo。Table_name WHERE Title LIKE '%qq%' OR Contents LIKE '%qq%'; 沒錯，這也是我第一個想到的方法。但是我們需要思考的是：隨著時間的推移，數據會越來越大，那個時候我們該如何提高我們的性能?用戶隨時都有可能再添加對Remark(備注)欄位進行查找，難道我們就應該不厭其煩地修改程序代碼? 需要指出的是：面對這樣的查詢條件，即使Title和Contents上都有索引，我們也無法使用到索引，因為在 '%qq%'的「qq」前面使用了通配符，所以無法使用到索引;如果查詢的條件是'qq%'，那到是可以利用上索引。
在許多資料庫性能調優的文章上都說OR這個謂詞可以使用SELECT UNION ALL SELECT這樣的方式來提高性能，但是需要提醒大家的是：如果在一條記錄中欄位Title和Contents都同時存在「中國」字元的話，那麼返回的結果就會出現兩條相同的記錄，如果你希望是唯一的記錄，那麼這個時候你就要注意了。
現在回到我們上面的問題，大概這個時候大家都應該想到了資料庫的全文索引了。全文索引是一種特殊類型的基於標記的功能性索引，由 Microsoft SQL Server 全文引擎 (MSFTESQL) 服務創建和維護。創建全文索引的過程與創建其他類型的索引的過程差別很大。
MSFTESQL 不是基於某一特定行中存儲的值來構造 B 樹結構，而是基於要索引的文本中的各個標記來創建倒排、堆積且壓縮的索引結構。(摘自MSDN) 為什麼說SQL Server 全文索引不是萬能的?可能大家都懷疑我是不是標題黨了，呵呵，馬上就講到，那就是這個全文索引能解決我們一開始提到的場景嗎?回答是否定。
為什麼呢?因為它的分詞和倒排索引造成了對字元串「tqq。tencent。com」這樣的內容進行『「*qq*」』這樣的條件查詢，上面那條記錄是不會被返回的。它的分詞應該是正向最大值的分詞方法，它沒有對方向再進行一次分詞和索引，索引無法查詢到。這個可能會被大家所忽略掉的。

Ⅸ 認識SQLServer索引以及單列索引和多列索引的不同

SQLServer索引是為了加快查詢的速度。
單列索引，就是以一個欄位建立的索引，如 學號 ;
多列索引，就是以一個以上的欄位建立的索引，如 學號,課程號。

Ⅹ sqlserver索引超出了數組界限如何解決

怕不是用sql server 2008R2的查詢分析器打開高版本的sql server 資料庫吧。

你可以無視錯誤直接打SQL，只是部分功能如sql server 代理不能使用而已。

想解決就裝一下更高版本的查詢分析器吧。