重構表的索引,非常費時的,因此只能在需要時進行。可以通過dbcc showcontig來判斷是否需要重構表的索引。
dbcc showcontig用法
下面舉例來說明dbcc showcontig和dbcc redbindex的使用方法。以應用程式中的employee資料表作為例子,在 sql server的query analyzer輸入命令:
declare @tid int
set @tid=object_id('bcc')
dbcc showcontig(@tid)
輸出結果:
通過分析這些結果可以知道該錶的索引是否需要重構。如下描述了每一行的意義:
資訊 描述
掃瞄頁數: 表或索引中的長頁數
掃瞄區數: 表或索引中的長區頁數
區切換次數:遍歷頁時從乙個區域到另乙個區域的次數
區掃瞄碎片: 掃瞄索引頁中失序頁的百分比
每頁的平均可用位元組數: 掃瞄頁面中平均自由位元組數
平均頁密度(滿): 平均頁密度,表示頁有多滿
從上執行結果看,最佳計數=實際計數,這表明bcc表不需要重構表索引。若不等的話,則視差異決定是否重建
附重構表sql dbcc dbreindex。
3. dbcc dbreindex 用法
重建指定資料庫中表的乙個或多個索引。
語法dbcc dbreindex
( [ 'database.owner.table_name'
[ , index_name
[ , fillfactor ]
引數'database.owner.table_name'
是要重建其指定的索引的表名。資料庫、所有者和表名必須符合識別符號的規則。有關更多資訊,請參見使用識別符號。如果提供 database 或 owner 部分,則必須使用單引號 (') 將整個 database.owner.table_name 括起來。如果只指定 table_name,則不需要單引號。
index_name
是要重建的索引名。索引名必須符合識別符號的規則。如果未指定 index_name 或指定為 ' ',就要對錶的所有索引進行重建。
fillfactor
是建立索引時每個索引頁上要用於儲存資料的空間百分比。fillfactor 替換起始填充因子以作為索引或任何其它重建的非聚集索引(因為已重建聚集索引)的新預設值。如果 fillfactor 為 0,dbcc dbreindex 在建立索引時將使用指定的起始 fillfactor。
--ext
dbcc dbreindex('spc.dbo.bcc','',90)
31 天重構學習筆記索引
由於最近在做重構的專案,所以對重構又重新進行了一遍學習和整理,對31天重構最早接觸是在2009年10月份,由於當時沒有訂閱sean chambers的blog,所以是在國外的社群上閒逛的時候鏈結過去的。記得當時一口氣看完了整個系列並沒有多少感覺,因為這些基本上專案都在使用,只是我們沒有專門把它標示和...
mysql 表 索引 mysql 為表新增索引
索引作用 在索引列上,除了上面提到的有序查詢之外,資料庫利用各種各樣的快速定位技術,能夠大大提高查詢效率。特別是當資料量非常大,查詢涉及多個表時,使用索引往往能使查詢速度加快成千上萬倍。例如,有3個未索引的表t1 t2 t3,分別只包含列c1 c2 c3,每個表分別含有1000行資料組成,指為1 1...
Confluence 6 重構查詢索引
查詢索引是自動維護的,但是你有時候可能會因為你在查詢的時候或檢視者郵件主題出現了異常,或者你的 confluence 例項公升級到了新的版本,你可能需要手動重構索引。進行搜尋索引重構 然後選擇general configuration鏈結。在左側面板的管理 administration 下面,選擇內...