轉(zhuǎn)帖|其它|編輯:郝浩|2010-06-01 11:52:17.000|閱讀 614 次
概述:索引的作用就類似于書的目錄,書的目錄會按照章節(jié)的順序排列,會指想某一張的位置。這樣如果在一本數(shù)百頁的書里面查找某個(gè)章節(jié)位置的時(shí)候,我們就可以只掃描書的目錄,掃描的范圍縮小了n倍,查詢的效率自然就提高了。本文介紹Asp.Net網(wǎng)站優(yōu)化之?dāng)?shù)據(jù)庫索引優(yōu)化方法。
# 界面/圖表報(bào)表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
索引的作用就類似于書的目錄,書的目錄會按照章節(jié)的順序排列,會指想某一張的位置。這樣如果在一本數(shù)百頁的書里面查找某個(gè)章節(jié)位置的時(shí)候,我們就可以只掃描書的目錄,掃描的范圍縮小了n倍,查詢的效率自然就提高了。另外在sql server內(nèi)存夠用的情況下索引會被放到內(nèi)存中,在內(nèi)存中查找自然又會提高效率;所以我們必須得合理利用索引。
1)對什么列建索引
數(shù)據(jù)庫默認(rèn)情況下會對主鍵建聚集索引,除了這個(gè)索引之外還需要在哪些列上建索引呢?這個(gè)問題只能具體情況具體分析,要看需要優(yōu)化的sql語句(通常是查詢次數(shù)多,查詢相應(yīng)想要高的語句),根據(jù)什么列的條件進(jìn)行查詢。
例如:在論壇的數(shù)據(jù)庫中有一張表是帖子回復(fù)表,在論壇的應(yīng)用中用到最多的就是對指定帖子的某一頁的回復(fù)進(jìn)行查詢,查詢回復(fù)表的條件是主貼的id;這時(shí)候在主貼字段上建索引就勢在必然。
2)一定要在主鍵上建聚集索引嗎
通常情況下sql server會自動(dòng)給主鍵加上聚集索引,但也有一些例外的情況我們需要把聚集索引建在其他列上,例如我們用到了表分區(qū),而分區(qū)的字段不是主鍵,這時(shí)候就需要將聚集索引建在分區(qū)的列上。另外如果查詢時(shí)根據(jù)主鍵查詢較少,而根據(jù)其他列的查詢較頻繁,則也可以考慮將聚集索引建在非主鍵上。單需要注意的是聚集索引的列必須是不易變的列,如果聚集索引變了一會引起聚集索引內(nèi)的記錄的搬遷,造成頁page的分離與碎片;二會引起每一個(gè)非聚 集索引被修改,以便于所有相關(guān)的非聚集索引的行的索引鍵的值被糾正。這既浪費(fèi)時(shí)間和空間,也導(dǎo)致需要整理的碎片,增加了不必要的開銷(每個(gè)列重組聚集鍵)。
3)復(fù)合索引(索引有兩個(gè)以上的列)要注意列順序
索引在數(shù)據(jù)庫中是以B樹的形式存儲的。包含A,B兩個(gè)列的索引會首先根據(jù)A列建B樹,A列的葉節(jié)點(diǎn)上才會開始根據(jù)B列建B樹。所以包含兩個(gè)列的索引就需要根據(jù)查詢條件所在列來決定兩個(gè)列在索引中的順序。
可以用下面的sql做實(shí)驗(yàn):
show sourceview sourceprint?01 USE [Test] 02 GO 03 /****** 對象: Table [dbo].[testIndexOrder] 腳本日期: 05/27/2010 09:11:26 ******/ 04 SET ANSI_NULLS ON 05 GO 06 SET QUOTED_IDENTIFIER ON 07 GO 08 CREATE TABLE [dbo].[testIndexOrder]( 09 [ID] [int] IDENTITY(1,1) NOT NULL, 10 [FirstName] [nvarchar](20) COLLATE Chinese_PRC_CI_AS NOT NULL, 11 [LastName] [nvarchar](20) COLLATE Chinese_PRC_CI_AS NOT NULL, 12 [Desc] [nvarchar](400) COLLATE Chinese_PRC_CI_AS NULL, 13 CONSTRAINT [PK_testIndexOrder] PRIMARY KEY CLUSTERED 14 ( 15 [ID] ASC 16 )WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY] 17 ) ON [PRIMARY] 18 GO 19 /****** 對象: Index [IX_testIndexOrder] 腳本日期: 05/27/2010 09:11:51 ******/ 20 CREATE NONCLUSTERED INDEX [IX_testIndexOrder] ON [dbo].[testIndexOrder] 21 ( 22 [FirstName] ASC, 23 [LastName] ASC 24 )WITH (SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF) ON [PRIMARY] 25 GO 26 declare @i INT; 27 DECLARE @random varchar(36); 28 set @i = 0; 29 while @i < 100000 30 begin 31 set @random = newid(); 32 33 INSERT INTO [testIndexOrder] 34 (FirstName,LastName,[Desc]) 35 VALUES( 36 substring(@random,1,8),substring(@random,12,8),@random 37 ); 38 set @i = @i + 1 39 end 40 41 42 set statistics time on 43 select * from [testIndexOrder] where lastname = '6F-4ECA-' 44 select * from [testIndexOrder] where firstname = 'CAABE009' 45 set statistics time off |
4)索引的個(gè)數(shù)問題
索引提高查詢效率是以降低更新、插入、刪除的速度為代價(jià)的。每當(dāng)索引列發(fā)生變化時(shí)都需要對索引數(shù)據(jù)進(jìn)行相應(yīng)的調(diào)整。所以一個(gè)表上不可以建太多的索引,除非你完全不在乎修改數(shù)據(jù)的效率。另外sql server本身會對索引的數(shù)量和索引的數(shù)據(jù)長度有限制,具體請參考
5)在必要時(shí)重建索引
Sql server運(yùn)行一段時(shí)間之后就會形成一些索引碎片,這時(shí)候就需要重建索引了,有時(shí)候重建索引可以起到意想不到的效果。
查看索引碎片,重建索引,可以通過sql server管理器來重建;也可以通過下面的sql語句來實(shí)現(xiàn):
view sourceprint?
1 --顯示表testIndexOrder的索引碎片情況 2 DBCC SHOWCONTIG(testIndexOrder) 3 4 --重建表的索引 5 --第一個(gè)參數(shù),可以是表名,也可以是表ID。 6 --第二個(gè)參數(shù),如果是'',表示影響該表的所有索引。 7 --第三個(gè)參數(shù),填充因子,即索引頁的數(shù)據(jù)填充程度。如果是,表示每一個(gè)索引頁都全部填滿,此時(shí)select效率最高,但以后要插入索引時(shí),就得移動(dòng)后面的所有頁,效率很低。如果是,表示使用先前的填充因子值。 8 DBCC DBREINDEX(testIndexOrder,'',) |
本站文章除注明轉(zhuǎn)載外,均為本站原創(chuàng)或翻譯。歡迎任何形式的轉(zhuǎn)載,但請務(wù)必注明出處、不得修改原文相關(guān)鏈接,如果存在內(nèi)容上的異議請郵件反饋至chenjj@fc6vip.cn
文章轉(zhuǎn)載自:網(wǎng)絡(luò)轉(zhuǎn)載