page=2'當(dāng)前頁
創(chuàng)新互聯(lián)建站專注于靈寶企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站設(shè)計(jì),商城建設(shè)。靈寶網(wǎng)站建設(shè)公司,為靈寶等地區(qū)提供建站服務(wù)。全流程按需網(wǎng)站策劃,專業(yè)設(shè)計(jì),全程項(xiàng)目跟蹤,創(chuàng)新互聯(lián)建站專業(yè)和態(tài)度為您提供的服務(wù)
pagesize = 20'分頁大小
IF page = 1 THEN
SQL = "select top " pagesize " * from YOURTABLE order by ID desc"
ELSE
SQL = "select top " pagesize " * from YOURTABLE where ID not in(select top "pagesize" ID from YOURTABLE where ext_area='歐美' and ext_type='動(dòng)作' order by ID desc) and ext_area='歐美' and ext_type='動(dòng)作' order by ID desc" 'where條件,里外都要加上
END IF
另外,團(tuán)IDC網(wǎng)上有許多產(chǎn)品團(tuán)購,便宜有口碑
在關(guān)系型數(shù)據(jù)庫中使用索引能夠提高數(shù)據(jù)庫性能,這一點(diǎn)是非常明顯的。用的索引越多,從數(shù)據(jù)庫系統(tǒng)中得到數(shù)據(jù)的速度就越快。然而,需要注意的是,用的索引越多,向數(shù)據(jù)庫系統(tǒng)中插入新數(shù)據(jù)所花費(fèi)的時(shí)間就越多。在本文中,你將了解到微軟的SQL Server數(shù)據(jù)庫所支持的各種不同類型的索引,在這里你將了解到如何使用不同的方法來實(shí)現(xiàn)索引,通過這些不同的實(shí)現(xiàn)方法,你在數(shù)據(jù)庫的讀性能方面得到的遠(yuǎn)比在數(shù)據(jù)庫的整體性能方面的損失要多得多。索引的定義索引是數(shù)據(jù)庫的工具,通過使用索引,在數(shù)據(jù)庫中獲取數(shù)據(jù)的時(shí)候,就可以不用掃描數(shù)據(jù)庫中的所有數(shù)據(jù)記錄,這樣能夠提高系統(tǒng)獲取數(shù)據(jù)的性能。使用索引可以改變數(shù)據(jù)的組織方式,使得所有的數(shù)據(jù)都是按照相似的結(jié)構(gòu)來組織的,這樣就可以很容易地實(shí)現(xiàn)數(shù)據(jù)的檢索訪問。索引是按照列來創(chuàng)建的,這樣就可以根據(jù)索引列中的值來幫助數(shù)據(jù)庫找到相應(yīng)的數(shù)據(jù)。索引的類型微軟的SQL Server 支持兩種類型的索引:clustered 索引和nonclustered索引。Clustered 索引在數(shù)據(jù)表中按照物理順序存儲(chǔ)數(shù)據(jù)。因?yàn)樵诒碇兄挥幸粋€(gè)物理順序,所以在每個(gè)表中只能有一個(gè)clustered索引。在查找某個(gè)范圍內(nèi)的數(shù)據(jù)時(shí),Clustered索引是一種非常有效的索引,因?yàn)檫@些數(shù)據(jù)在存儲(chǔ)的時(shí)候已經(jīng)按照物理順序排好序了。 Nonclustered索引不會(huì)影響到下面的物理存儲(chǔ),但是它是由數(shù)據(jù)行指針構(gòu)成的。如果已經(jīng)存在一個(gè)clustered索引,在nonclustered中的索引指針將包含clustered索引的位置參考。這些索引比數(shù)據(jù)更緊促,而且對(duì)這些索引的掃描速度比對(duì)實(shí)際的數(shù)據(jù)表掃描要快得多。 得到更好的性能 雖然索引可以帶來性能上的優(yōu)勢(shì),但是同時(shí)也將帶來一定的代價(jià)。雖然SQL Server系統(tǒng)允許你在每個(gè)數(shù)據(jù)表中創(chuàng)建多達(dá)256個(gè)nonclustered索引,但是建議不要使用這么多的索引。因?yàn)樗饕枰趦?nèi)存和物理磁盤驅(qū)動(dòng)器上使用更多的存儲(chǔ)空間。在執(zhí)行插入聲明的過程中可能會(huì)在一定程度上導(dǎo)致系統(tǒng)性能的下降,因?yàn)樵诓迦霐?shù)據(jù)的時(shí)候是需要根據(jù)索引的順序插入,而不是在第一個(gè)可用的位置直接插入數(shù)據(jù),這樣一來,存在的索引越多將導(dǎo)致插入或者更新聲明所需要的時(shí)間就越多。 在使用SQL Server系統(tǒng)創(chuàng)建索引的時(shí)候,建議參照下面的創(chuàng)建準(zhǔn)則來實(shí)現(xiàn): 正確的選擇數(shù)據(jù)類型 在索引中使用某些數(shù)據(jù)類型可以提高數(shù)據(jù)庫系統(tǒng)的效率,例如,Int,bigint, smallint,和tinyint等這些數(shù)據(jù)類型都非常適合于用在索引中,因?yàn)樗麄兌颊加孟嗤笮〉目臻g并且可以很容易地實(shí)現(xiàn)比較操作。其他的數(shù)據(jù)類型如char和varchar的效率都非常低,因?yàn)檫@些數(shù)據(jù)類型都不適合于執(zhí)行數(shù)學(xué)操作,并且執(zhí)行比較操作的時(shí)間都比上面提到數(shù)據(jù)類型要長。 確保在使用的過程中正確的利用索引值 在創(chuàng)建多列索引時(shí),需要注意列的順序 數(shù)據(jù)庫將根據(jù)第一列索引的值來排列記錄,然后進(jìn)一步根據(jù)第二列的值來排序,依次排序直到最后一個(gè)索引排序完畢。哪一列唯一數(shù)據(jù)值較少,哪一列就應(yīng)該為第一個(gè)索引,這樣可以確保數(shù)據(jù)可以通過索引進(jìn)一步交叉排序。 在clustered索引中限制列的數(shù)量 在clustered索引中用到的列越多,在nonclustered索引中包含的clustered索引參考位置就越多,需要存儲(chǔ)的數(shù)據(jù)也就越多。這樣將增加包含索引的數(shù)據(jù)表的大小,并且將增加基于索引的搜索時(shí)間。 避免頻繁更新clustered索引數(shù)據(jù)列 由于nonclustered 索引依賴于clustered 索引,所以如果構(gòu)成clustered 索引的數(shù)據(jù)列頻繁更新,將導(dǎo)致在nonclustered中存儲(chǔ)的行定位器也將隨之頻繁更新。對(duì)于所有與這些列相關(guān)的查詢來說,如果發(fā)生記錄被鎖定的情況時(shí),這將可能導(dǎo)致性能成本的增加。 分開操作(如果可能的話) 對(duì)于一個(gè)表來說,如果需要進(jìn)行頻繁的執(zhí)行插入、更新操作,同時(shí)還有大量讀操作的話,在可能的情況下嘗試將這個(gè)表分開操作。所有的插入和更新操作可以在一個(gè)沒有索引的表中操作,然后將其復(fù)制到另外一個(gè)表中,在這個(gè)表里有大量的索引可以優(yōu)化讀數(shù)據(jù)的能力。 適當(dāng)?shù)闹亟ㄋ饕?Nonclustered索引包含clustered索引的指針,這樣一來Nonclustered索引將從屬于clustered 索引。當(dāng)重建clustered索引時(shí),首先是丟棄原來的索引,然后再使用CREATE INDEX 來創(chuàng)建索引,或者在使用CREATE INDEX 聲明的同時(shí)將DROP_EXISTING 子句作為重建索引的一部分。將丟棄和創(chuàng)建分為幾步將會(huì)導(dǎo)致多次重建nonclustered 索引,而不象使用DROP_EXISTING 子句那樣,只重建一次nonclustered 索引。 明智的使用填充因子 數(shù)據(jù)存儲(chǔ)在那些具有固定大小的連續(xù)內(nèi)存頁面內(nèi)。隨著新的記錄行的加入,數(shù)據(jù)內(nèi)存頁將逐漸被填滿,系統(tǒng)就必須執(zhí)行數(shù)據(jù)頁的拆分工作,通過這個(gè)拆分工作將部分?jǐn)?shù)據(jù)轉(zhuǎn)移到下一個(gè)新的頁面當(dāng)中。這樣的拆分之后,將加重系統(tǒng)的負(fù)擔(dān),并且會(huì)導(dǎo)致存儲(chǔ)的數(shù)據(jù)支離破碎。填充因子可以維護(hù)數(shù)據(jù)之間的缺口,一般在創(chuàng)建索引的時(shí)候,該索引的填充因子就已經(jīng)被設(shè)置好了。這樣一來,可以減少插入數(shù)據(jù)所引起的頁面分裂的次數(shù)。因?yàn)橹皇窃趧?chuàng)建索引的時(shí)候才維護(hù)空間的大小,在增加數(shù)據(jù)或者更新數(shù)據(jù)時(shí)不會(huì)去維護(hù)空間的大小。因此,要想能夠充分的利用填充因子,就必須周期性的重建索引。由填充因子所造成的缺口將導(dǎo)致讀性能的下降,因?yàn)殡S著數(shù)據(jù)庫的擴(kuò)張,越來越多的磁盤存取工作需要讀取數(shù)據(jù)。所以,在讀的次數(shù)超過寫的次數(shù)的時(shí)候,很重要的一點(diǎn)是考慮使用填充因子還是使用缺省方式合適。 管理層的決策 通過有效的使用索引,可以在微軟的SQL Server系統(tǒng)中實(shí)現(xiàn)很好的查詢功能,但是使用索引的效率取決于幾種不同的實(shí)現(xiàn)決策。在索引的性能平衡方面,要做出正確的數(shù)據(jù)庫管理決策意味著需要在良好的性能和困境中抉擇。在特定的情況下,本文給出的一些建議將有助于你做出正確的決策。
分兩步實(shí)現(xiàn)
一、分頁的存儲(chǔ)過程如下
set ANSI_NULLS ON
set QUOTED_IDENTIFIER ON
go
CREATE PROCEDURE [dbo].[Pagination]
@tblName varchar(255), -- 表名
@strGetFields varchar(1000) , -- 需要返回的列
@fldName varchar(255), -- 排序的字段名
@PageSize int, -- 頁尺寸
@PageIndex int , -- 頁碼
@doCount bit=0, -- 返回記錄總數(shù), 非 0 值則返回
@OrderType bit, -- 設(shè)置排序類型, 非 0 值則降序
@strWhere varchar(1500) -- 查詢條件 (注意: 不要加 where)
AS
declare @strSQL varchar(5000) -- 主語句
declare @strTmp varchar(110) -- 臨時(shí)變量
declare @strOrder varchar(400) -- 排序類型
if @doCount != 0
begin
if @strWhere !=''
set @strSQL = 'select count(*) as Total from [' + @tblName + '] where ' + @strWhere
else
set @strSQL = 'select count(*) as Total from [' + @tblName + ']'
end
--以上代碼的意思是如果@doCount傳遞過來的不是0,就執(zhí)行總數(shù)統(tǒng)計(jì)。以下的所有代碼都是@doCount為0的情況
else
begin
if @OrderType != 0
begin
set @strTmp = '(select min'
set @strOrder = ' order by [' + @fldName + '] desc'
end
--如果@OrderType不是0,就執(zhí)行降序,這句很重要!
else
begin
set @strTmp = '(select max'
set @strOrder = ' order by [' + @fldName + '] asc'
end
if @PageIndex = 1
begin
if @strWhere != ''
set @strSQL = 'select top ' + str(@PageSize) + ' ' + @strGetFields + ' from [' + @tblName + '] where '
+ @strWhere + ' ' + @strOrder
else
set @strSQL = 'select top ' + str(@PageSize) + ' ' + @strGetFields
+ ' from [' + @tblName + '] ' + @strOrder
end
--如果是第一頁就執(zhí)行以上代碼,這樣會(huì)加快執(zhí)行速度
else
begin
--以下代碼賦予了@strSQL以真正執(zhí)行的SQL代碼
set @strSQL = 'select top ' + str(@PageSize) + ' ' + @strGetFields + ' from ['
+ @tblName + '] where [' + @fldName + ']' + @strTmp + '(['+ @fldName + ']) from (select top '
+ str( ( @PageIndex - 1 ) * @PageSize ) + ' ['+ @fldName + '] from [' + @tblName + ']'
+ @strOrder + ') as tblTmp)' + @strOrder
if @strWhere != ''
set @strSQL = 'select top ' + str(@PageSize) + ' ' + @strGetFields + ' from ['
+ @tblName + '] where [' + @fldName + ']' + @strTmp + '(['
+ @fldName + ']) from (select top ' + str( ( @PageIndex - 1 ) * @PageSize ) + ' ['
+ @fldName + '] from [' + @tblName + '] where ' + @strWhere + ' '
+ @strOrder + ') as tblTmp) and ' + @strWhere + ' ' + @strOrder
end
end
exec(@strSQL)
二、頁面調(diào)用部分代碼
Function navindex(ByVal PageIndextemp As Integer, ByVal PageSizetemp As Integer, ByVal countint As Integer, ByVal pagename As String) As String
Dim i As Integer
If countint Mod PageSizetemp = 0 Then
i = countint \ PageSizetemp
Else
i = countint \ PageSizetemp + 1
End If
Dim maxi, mini As Integer
Dim navleft, navright, navstrtemp As String
If i 10 Then
maxi = i
mini = 1
Else
maxi = pageindex + 3
mini = pageindex - 3
If mini 1 Then
navleft = "a href=""" pagename "?page=" (mini - 1) """ class=""link_nav_btn""/a "
Else
mini = 1
maxi = 10
End If
If maxi i Then
navright = " a href=""" pagename "?page=" (maxi + 1) """ class=""link_nav_btn""/a"
Else
If i - 10 0 Then
mini = i - 10
Else
mini = 1
End If
maxi = i
End If
End If
For n As Integer = mini To maxi
If n = pageindex Then
navstrtemp = navstrtemp " a href=""" pagename "?page=" n """ class=""link_nav_btn_select""b" n "/b/a"
Else
navstrtemp = navstrtemp " a href=""" pagename "?page=" n """ class=""link_nav_btn""" n "/a"
End If
Next
navstrtemp = navleft navstrtemp navright
Return navstrtemp
End Function
Sub databinds(ByVal tblnametemp As String, ByVal strGetFieldstemp As String, ByVal fldNametemp As String, ByVal PageSizetemp As Integer, ByVal PageIndextemp As Integer, ByVal OrderTypetemp As Short, ByVal strWheretemp As String)
'tblnametemp表名,strGetFieldstemp需要返回的列,fldNametemp排序的字段名,PageSizetemp頁尺寸,PageIndextemp頁碼,OrderTypetemp設(shè)置排序類型,strWheretemp查詢條件
'總數(shù)
cmdTM = New SqlCommand("select count(*) from " tblnametemp " where " strWheretemp, conPubs)
conPubs.Open()
countint = CInt(cmdTM.ExecuteScalar())
conPubs.Close()
'導(dǎo)航
navstr = navindex(PageIndextemp, PageSizetemp, countint, "newshyxh.aspx")
'分頁
cmdTM = New SqlCommand("Pagination", conPubs)
cmdTM.CommandType = CommandType.StoredProcedure
'add input
cmdTM.Parameters.Add("@tblName", SqlDbType.VarChar, 255).Value = tblnametemp
cmdTM.Parameters.Add("@strGetFields", SqlDbType.VarChar, 1000).Value = strGetFieldstemp
cmdTM.Parameters.Add("@fldName", SqlDbType.VarChar, 255).Value = fldNametemp
cmdTM.Parameters.Add("@PageIndex", SqlDbType.Int).Value = PageIndextemp
cmdTM.Parameters.Add("@PageSize", SqlDbType.Int).Value = PageSizetemp
cmdTM.Parameters.Add("@OrderType", SqlDbType.Bit).Value = OrderTypetemp
cmdTM.Parameters.Add("@strWhere", SqlDbType.VarChar, 1500).Value = strWheretemp
conPubs.Open()
newsright.DataSource = cmdTM.ExecuteReader()
newsright.DataBind()
conPubs.Close()
End Sub
存儲(chǔ)過程:create Procedure pname
( @pageIndex int,@pageSize)
as
select * from tableName order by id
offset @pageIndex * pageSize fetch next pageSize rows only
分頁:
sqlserver 在2008之前 使用 top 和 not int top 的方式來做分頁
2008以后使用 row_number() 函數(shù)作為分頁關(guān)鍵函數(shù)
2012使用 offset 1 fetch next 10 rows only
你問了2個(gè)問題,你可以優(yōu)先把視圖,存儲(chǔ)過程,觸發(fā)器等弄明白,分頁是查詢,在存儲(chǔ)過程里可以寫復(fù)雜的sql文,只是在運(yùn)行時(shí)是預(yù)編譯和參數(shù)化查詢防止sql注入
在良好的數(shù)據(jù)庫設(shè)計(jì)基礎(chǔ)上,能有效地使用索引是SQL Server取得高性能的基礎(chǔ),SQL Server采用基于代價(jià)的優(yōu)化模型,它對(duì)每一個(gè)提交的有關(guān)表的查詢,決定是否使用索引或用哪一個(gè)索引。因?yàn)椴樵儓?zhí)行的大部分開銷是磁盤I/O,使用索引提高性能的一個(gè)主要目標(biāo)是避免全表掃描,因?yàn)槿頀呙栊枰獜拇疟P上讀表的每一個(gè)數(shù)據(jù)頁,如果有索引指向數(shù)據(jù)值,則查詢只需讀幾次磁盤就可以了。
所以如果建立了合理的索引,優(yōu)化器就能利用索引加速數(shù)據(jù)的查詢過程。但是,索引并不總是提高系統(tǒng)的性能,在增、刪、改操作中索引的存在會(huì)增加一定的工作量,因此,在適當(dāng)?shù)牡胤皆黾舆m當(dāng)?shù)乃饕牟缓侠淼牡胤絼h除次優(yōu)的索引,將有助于優(yōu)化那些性能較差的SQL Server應(yīng)用。實(shí)踐表明,合理的索引設(shè)計(jì)是建立在對(duì)各種查詢的分析和預(yù)測上的,只有正確地使索引與程序結(jié)合起來,才能產(chǎn)生最佳的優(yōu)化方案。本文就SQL Server索引的性能問題進(jìn)行了一些分析和實(shí)踐。
一、聚簇索引(clustered indexes)的使用
聚簇索引是一種對(duì)磁盤上實(shí)際數(shù)據(jù)重新組織以按指定的一個(gè)或多個(gè)列的值排序。由于聚簇索引的索引頁面指針指向數(shù)據(jù)頁面,所以使用聚簇索引查找數(shù)據(jù)幾乎總是比使用非聚簇索引快。每張表只能建一個(gè)聚簇索引,并且建聚簇索引需要至少相當(dāng)該表120%的附加空間,以存放該表的副本和索引中間頁。建立聚簇索引的思想是:
1、大多數(shù)表都應(yīng)該有聚簇索引或使用分區(qū)來降低對(duì)表尾頁的競爭,在一個(gè)高事務(wù)的環(huán)境中,對(duì)最后一頁的封鎖嚴(yán)重影響系統(tǒng)的吞吐量。
2、在聚簇索引下,數(shù)據(jù)在物理上按順序排在數(shù)據(jù)頁上,重復(fù)值也排在一起,因而在那些包含范圍檢查(between、、=、、=)或使用group by或order by的查詢時(shí),一旦找到具有范圍中第一個(gè)鍵值的行,具有后續(xù)索引值的行保證物理上毗連在一起而不必進(jìn)一步搜索,避免了大范圍掃描,可以大大提高查詢速度。
3、在一個(gè)頻繁發(fā)生插入操作的表上建立聚簇索引時(shí),不要建在具有單調(diào)上升值的列(如IDENTITY)上,否則會(huì)經(jīng)常引起封鎖沖突。
4、在聚簇索引中不要包含經(jīng)常修改的列,因?yàn)榇a值修改后,數(shù)據(jù)行必須移動(dòng)到新的位置。
5、選擇聚簇索引應(yīng)基于where子句和連接操作的類型。
聚簇索引的侯選列是:
1、主鍵列,該列在where子句中使用并且插入是隨機(jī)的。
2、按范圍存取的列,如pri_order 100 and pri_order 200。
3、在group by或order by中使用的列。
4、不經(jīng)常修改的列。
5、在連接操作中使用的列。
二、非聚簇索引(nonclustered indexes)的使用
SQL Server缺省情況下建立的索引是非聚簇索引,由于非聚簇索引不重新組織表中的數(shù)據(jù),而是對(duì)每一行存儲(chǔ)索引列值并用一個(gè)指針指向數(shù)據(jù)所在的頁面。換句話說非聚簇索引具有在索引結(jié)構(gòu)和數(shù)據(jù)本身之間的一個(gè)額外級(jí)。一個(gè)表如果沒有聚簇索引時(shí),可有250個(gè)非聚簇索引。每個(gè)非聚簇索引提供訪問數(shù)據(jù)的不同排序順序。在建立非聚簇索引時(shí),要權(quán)衡索引對(duì)查詢速度的加快與降低修改速度之間的利弊。另外,還要考慮這些問題:
1、索引需要使用多少空間。
2、合適的列是否穩(wěn)定。
3、索引鍵是如何選擇的,掃描效果是否更佳。
4、是否有許多重復(fù)值。
對(duì)更新頻繁的表來說,表上的非聚簇索引比聚簇索引和根本沒有索引需要更多的額外開銷。對(duì)移到新頁的每一行而言,指向該數(shù)據(jù)的每個(gè)非聚簇索引的頁級(jí)行也必須更新,有時(shí)可能還需要索引頁的分理。從一個(gè)頁面刪除數(shù)據(jù)的進(jìn)程也會(huì)有類似的開銷,另外,刪除進(jìn)程還必須把數(shù)據(jù)移到頁面上部,以保證數(shù)據(jù)的連續(xù)性。所以,建立非聚簇索引要非常慎重。非聚簇索引常被用在以下情況:
1、某列常用于集合函數(shù)(如Sum,....)。
2、某列常用于join,order by,group by。
3、查尋出的數(shù)據(jù)不超過表中數(shù)據(jù)量的20%。
三、覆蓋索引(covering indexes)的使用
覆蓋索引是指那些索引項(xiàng)中包含查尋所需要的全部信息的非聚簇索引,這種索引之所以比較快也正是因?yàn)樗饕撝邪瞬閷に仨毜臄?shù)據(jù),不需去訪問數(shù)據(jù)頁。如果非聚簇索引中包含結(jié)果數(shù)據(jù),那么它的查詢速度將快于聚簇索引。
但是由于覆蓋索引的索引項(xiàng)比較多,要占用比較大的空間。而且update操作會(huì)引起索引值改變。所以如果潛在的覆蓋查詢并不常用或不太關(guān)鍵,則覆蓋索引的增加反而會(huì)降低性能。
四、索引的選擇技術(shù)
p_detail是住房公積金管理系統(tǒng)中記錄個(gè)人明細(xì)的表,有890000行,觀察在不同索引下的查詢運(yùn)行效果,測試在C/S環(huán)境下進(jìn)行,客戶機(jī)是IBM PII350(內(nèi)存64M),服務(wù)器是DEC Alpha1000A(內(nèi)存128M),數(shù)據(jù)庫為SYBASE11.0.3。
1、 select count(*) from p_detail where
op_date’19990101’ and op_date’
19991231’ and pri_surplus1300
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秒
從以上查詢效果分析,索引的有無,建立方式的不同將會(huì)導(dǎo)致不同的查詢效果,選擇什么樣的索引基于用戶對(duì)數(shù)據(jù)的查詢條件,這些條件體現(xiàn)于where從句和join表達(dá)式中。一般來說建立索引的思路是:
(1)主鍵時(shí)常作為where子句的條件,應(yīng)在表的主鍵列上建立聚簇索引,尤其當(dāng)經(jīng)常用它作為連接的時(shí)候。
(2)有大量重復(fù)值且經(jīng)常有范圍查詢和排序、分組發(fā)生的列,或者非常頻繁地被訪問的列,可考慮建立聚簇索引。
(3)經(jīng)常同時(shí)存取多列,且每列都含有重復(fù)值可考慮建立復(fù)合索引來覆蓋一個(gè)或一組查詢,并把查詢引用最頻繁的列作為前導(dǎo)列,如果可能盡量使關(guān)鍵查詢形成覆蓋查詢。
(4)如果知道索引鍵的所有值都是唯一的,那么確保把索引定義成唯一索引。
(5)在一個(gè)經(jīng)常做插入操作的表上建索引時(shí),使用fillfactor(填充因子)來減少頁分裂,同時(shí)提高并發(fā)度降低死鎖的發(fā)生。如果在只讀表上建索引,則可以把fillfactor置為100。
(6)在選擇索引鍵時(shí),設(shè)法選擇那些采用小數(shù)據(jù)類型的列作為鍵以使每個(gè)索引頁能夠容納盡可能多的索引鍵和指針,通過這種方式,可使一個(gè)查詢必須遍歷的索引頁面降到最小。此外,盡可能地使用整數(shù)為鍵值,因?yàn)樗軌蛱峁┍热魏螖?shù)據(jù)類型都快的訪問速度。
五、索引的維護(hù)
上面講到,某些不合適的索引影響到SQL Server的性能,隨著應(yīng)用系統(tǒng)的運(yùn)行,數(shù)據(jù)不斷地發(fā)生變化,當(dāng)數(shù)據(jù)變化達(dá)到某一個(gè)程度時(shí)將會(huì)影響到索引的使用。這時(shí)需要用戶自己來維護(hù)索引。索引的維護(hù)包括:
1、重建索引
隨著數(shù)據(jù)行的插入、刪除和數(shù)據(jù)頁的分裂,有些索引頁可能只包含幾頁數(shù)據(jù),另外應(yīng)用在執(zhí)行大塊I/O的時(shí)候,重建非聚簇索引可以降低分片,維護(hù)大塊I/O的效率。重建索引實(shí)際上是重新組織B-樹空間。在下面情況下需要重建索引:
(1)數(shù)據(jù)和使用模式大幅度變化。
(2)排序的順序發(fā)生改變。
(3)要進(jìn)行大量插入操作或已經(jīng)完成。
(4)使用大塊I/O的查詢的磁盤讀次數(shù)比預(yù)料的要多。
(5)由于大量數(shù)據(jù)修改,使得數(shù)據(jù)頁和索引頁沒有充分使用而導(dǎo)致空間的使用超出估算。
(6)dbcc檢查出索引有問題。
當(dāng)重建聚簇索引時(shí),這張表的所有非聚簇索引將被重建。
2、索引統(tǒng)計(jì)信息的更新
當(dāng)在一個(gè)包含數(shù)據(jù)的表上創(chuàng)建索引的時(shí)候,SQL Server會(huì)創(chuàng)建分布數(shù)據(jù)頁來存放有關(guān)索引的兩種統(tǒng)計(jì)信息:分布表和密度表。優(yōu)化器利用這個(gè)頁來判斷該索引對(duì)某個(gè)特定查詢是否有用。但這個(gè)統(tǒng)計(jì)信息并不動(dòng)態(tài)地重新計(jì)算。這意味著,當(dāng)表的數(shù)據(jù)改變之后,統(tǒng)計(jì)信息有可能是過時(shí)的,從而影響優(yōu)化器追求最有工作的目標(biāo)。因此,在下面情況下應(yīng)該運(yùn)行update statistics命令:
(1)數(shù)據(jù)行的插入和刪除修改了數(shù)據(jù)的分布。
(2)對(duì)用truncate table刪除數(shù)據(jù)的表上增加數(shù)據(jù)行。
(3)修改索引列的值。
六、結(jié)束語
實(shí)踐表明,不恰當(dāng)?shù)乃饕坏谑聼o補(bǔ),反而會(huì)降低系統(tǒng)的執(zhí)行性能。因?yàn)榇罅康乃饕诓迦?、修改和刪除操作時(shí)比沒有索引花費(fèi)更多的系統(tǒng)時(shí)間。例如下面情況下建立的索引是不恰當(dāng)?shù)模?/p>
1、在查詢中很少或從不引用的列不會(huì)受益于索引,因?yàn)樗饕苌倩驈膩聿槐厮阉骰谶@些列的行。
2、只有兩個(gè)或三個(gè)值的列,如男性和女性(是或否),從不會(huì)從索引中得到好處。
另外,鑒于索引加快了查詢速度,但減慢了數(shù)據(jù)更新速度的特點(diǎn)??赏ㄟ^在一個(gè)段上建表,而在另一個(gè)段上建其非聚簇索引,而這兩段分別在單獨(dú)的物理設(shè)備上來改善操作性能。
文章名稱:sqlserver頁分裂,sqlserver分頁語句
本文網(wǎng)址:http://www.rwnh.cn/article32/dssohpc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供電子商務(wù)、搜索引擎優(yōu)化、虛擬主機(jī)、做網(wǎng)站、企業(yè)網(wǎng)站制作、動(dòng)態(tài)網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)