① sqlSERVER壓縮數據文件的用處有多大
前奏：前些天因為客戶那邊的問題（其實是盜版問題），只能使用免費的SQLSERVER EXPRESS版本express版本的SQLSERVER的整個資料庫的數據文件大小限制為4GB，就是說不管你用多少個文件組，多少個輔助數據文件ndf所有加起來都不能超過4GB（mdf+ndf）事務日誌文件大小沒有限制因為我們的資料庫只是使用了一個主數據文件GPOS.mdf和一個事務日誌文件GPOS.ldf 本人的解決思路：本人在想如果是這樣，到時候就收縮資料庫唄在網上查了一下資料：由於DBCC SHRINKDATABASE一次運行會同時影響所有的文件（包括數據文件和日誌文件），使用者不能指定每個文件的目標大小，其結果可能不能達到預期的要求。所以建議先做好規劃，對每個文件確定預期目標，然後使用DBCC SHRINKFILE來一個文件一個文件地做比較穩妥本來很開心的，網上資料都說使用DBCC SHRINKFILE來收縮文件，那這樣就不怕拉 （我不怕不怕拉~）但是，往下看那個資料：1、首先了解數據文件當前的使用情況收縮量的大小不可能超過當前文件的空閑空間的大小。如果想要壓縮資料庫的大小，首先要確認數據文件里的確有相應未被使用的空間。如果空間都在使用中，那就要確認大量佔用空間的對象（表格或索引）。然後通過歸檔歷史數據，先把空間釋放出來 2、主數據文件（primary file）是不能被清空的。能被完全清空的只有輔助數據文件 3、如果要把一個文件組整個清空，要刪除分配在這個文件組上的對象（表格或索引），或者把他們移到其他文件組上。DBCC SHRINKFILE不會幫你做這個工作把數據文件裡面數據和對象清除完、確認數據文件（組）有足夠的空閑空間後，管理員就可以使用DBCC SHRINKFILE來縮小或清空指定文件了。如果要縮小文件，就填上需要的target_size，如果要清空文件，就選擇EMPTYFILE 根據上面資料所說，本人的解決思路是：1、確認大量佔用空間的對象（表格或索引）。然後通過歸檔歷史數據，先把空間釋放出來再壓縮數據文件2、重建索引，把一些數據頁面重排一次，原先的頁面被釋放，所佔用的分區也被釋放，再去DBCC SHRINKFILE如果你們有其他解決方法希望你們告訴我，謝謝您們了！！
② sqlserver索引碎片怎麼避免
毫無疑問，給表添加索引是有好處的，你要做的大部分工作就是維護索引，在數據更改期間索引可能產生碎片，所以一些維護是必要的。碎片可能是你查詢產生性能問題的來源。
那麼到底什麼是索引碎片呢？索引碎片實際上有2種形式：外部碎片和內部碎片。不管哪種碎片基本上都會影響索引內頁的使用。這也許是因為頁的邏輯順序錯誤（即外部碎片）或每頁存儲的數據量少於數據頁的容量（內部錯誤）。無論索引產生了哪種類型的碎片，你都會因為它而面臨查詢的性能問題。
外部碎片
當 索引頁不在邏輯順序上時就會產生外部碎片。索引創建時，索引鍵按照邏輯順序放在一組索引頁上。當新數據插入索引時，新的鍵可能放在存在的鍵之間。為了讓新 的鍵按照正確的順序插入，可能會創建新的索引頁來存儲需要移動的那些存在的鍵。這些新的索引頁通常物理上不會和那些被移動的鍵原來所在的頁相鄰。創建新頁 的過程會引起索引頁偏離邏輯順序。
下面的例子將比實際的言論更加清晰的解釋這個概念。
假定在任何另外的數據插入你的表之前存在索引上的結構如下
（註：下面圖片里應該是7和8，原文里是6和8）：
INSERT語句往索引里添加新的數據，假定添加的是5。INSERT將引起新頁創建，為了給5在原來的頁上留出空間，7和8被移到了新頁上。這個創建將引起索引頁偏離邏輯順序。
在有特定搜索或者返回無序結果集的查詢的情況下，偏離順序的索引頁不會引起問題。對於返回有序結果集的查詢，搜索那些無序的索引頁需要進行額外的處理。有序結果集的例子如查詢返回4到10之間的記錄。為了返回7和8，查詢不得不進行額外的頁切換。雖然一個額外的頁切換在一個長時間運行里是無關緊要的，然而想像一下一個有好幾百頁偏離順序的非常大的表的情形。
內部碎片
當索引頁沒有用到最大量時就產生了內部碎片。雖然在一個有頻繁數據插入的應用程序里這也許有幫助，然而設置一個fill factor（填充因子）會在索引頁上留下空間，伺服器內部碎片會導致索引尺寸增加，從而在返回需要的數據時要執行額外的讀操作。這些額外的讀操作會降低查詢的性能。
怎樣確定索引是否有碎片？
SQLServer提供了一個資料庫命令――DBCC SHOWCONTIG――來確定一個指定的表或索引是否有碎片。
DBCC SHOWCONTIG
資料庫平台命令，用來顯示指定的表的數據和索引的碎片信息。
DBCC SHOWCONTIG 許可權默認授予 sysadmin固定伺服器角色或 db_owner 和 db_ddladmin固定資料庫角色的成員以及表的所有者且不可轉讓。
語法（SQLServer2000）
DBCC SHOWCONTIG
[ ( { table_name | table_id| view_name | view_id }
[ , index_name | index_id ]
)
]
[ WITH { ALL_INDEXES
| FAST [ , ALL_INDEXES ]
| TABLERESULTS [ , { ALL_INDEXES } ]
[ , { FAST | ALL_LEVELS } ]
}
]
語法（SQLServer7.0）
DBCC SHOWCONTIG
[ ( table_id [,index_id ]
)
]
示例：
顯示資料庫里所有索引的碎片信息
SET NOCOUNT ON
USE pubs
DBCC SHOWCONTIG WITH ALL_INDEXES
GO
顯示指定表的所有索引的碎片信息
SET NOCOUNT ONUSE pubs
DBCC SHOWCONTIG (authors) WITH ALL_INDEXES
GO
顯示指定索引的碎片信息
SET NOCOUNT ON
USE pubs
DBCC SHOWCONTIG (authors,aunmind)
GO
結果集
DBCC SHOWCONTIG將返回掃描頁數、掃描擴展盤區數、遍歷索引或表的頁時，DBCC 語句從一個擴展盤區移動到其它擴展盤區的次數、每個擴展盤區的頁數、掃描密度（最佳值是指在一切都連續地鏈接的情況下，擴展盤區更改的理想數目）。
DBCC SHOWCONTIG 正在掃描 'authors' 表...
表: 'authors'（1977058079）；
索引 ID: 1，資料庫 ID: 5
已執行 TABLE 級別的掃描。
- 掃描頁數.....................................: 1
- 掃描擴展盤區數...............................: 1
- 擴展盤區開關數...............................: 0
- 每個擴展盤區上的平均頁數.....................: 1.0
- 掃描密度［最佳值:實際值］....................: 100.00%［1:1］
- 邏輯掃描碎片.................................: 0.00%
- 擴展盤區掃描碎片.............................: 0.00%
- 每頁上的平均可用位元組數.......................: 6010.0
- 平均頁密度（完整）...........................: 25.75%
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
尋找什麼
掃描頁數：如果你知道行的近似尺寸和表或索引里的行數，那麼你可以估計出索引里的頁數。看看掃描頁數，如果明顯比你估計的頁數要高，說明存在內部碎片。
掃描擴展盤區數：用掃描頁數除以8,四捨五入到下一個最高值。該值應該和DBCC SHOWCONTIG返回的掃描擴展盤區數一致。如果DBCC SHOWCONTIG返回的數高，說明存在外部碎片。碎片的嚴重程度依賴於剛才顯示的值比估計值高多少。
擴展盤區開關數：該數應該等於掃描擴展盤區數減1。高了則說明有外部碎片。
每個擴展盤區上的平均頁數：該數是掃描頁數除以掃描擴展盤區數，一般是8。小於8說明有外部碎片。
掃描密度［最佳值:實際值］：DBCC SHOWCONTIG返回最有用的一個百分比。這是擴展盤區的最佳值和實際值的比率。該百分比應該盡可能靠近100％。低了則說明有外部碎片。
邏輯掃描碎片：無序頁的百分比。該百分比應該在0％到10％之間，高了則說明有外部碎片。
擴展盤區掃描碎片：無序擴展盤區在掃描索引葉級頁中所佔的百分比。該百分比應該是0％，高了則說明有外部碎片。
每頁上的平均可用位元組數：所掃描的頁上的平均可用位元組數。越高說明有內部碎片，不過在你用這個數字決定是否有內部碎片之前，應該考慮fill factor（填充因子）。
平均頁密度（完整）：每頁上的平均可用位元組數的百分比的相反數。低的百分比說明有內部碎片。
備注
DBCC SHOWCONTIG實際上僅對那些大表有用。小表顯示的結果根本不符合正常標准，因為他們也許沒有由多於8個的頁面組成。你在查看小表上執行DBCC SHOWCONTIG的結果時應該忽略一些結果。在處理小表時只需關心擴展盤區開關數、邏輯掃描碎片、每頁上的平均可用位元組數、平均頁密度（完整）。
DBCC SHOWCONTIG默認輸出的結果是：掃描頁數、掃描擴展盤區數、擴展盤區開關數、每個擴展盤區上的平均頁數、掃描密度［最佳值:實際值］、邏輯掃描碎片、擴展盤區掃描碎片、每頁上的平均可用位元組數、平均頁密度（完整）。可以用FAST和TABLERESULTS選項來控制這個輸出結果。
FAST選項指定執行索引的快速掃描，輸出結果是最小的，該選項不讀索引的葉或數據頁且只返回掃描頁數、掃描擴展盤區數、掃描密度［最佳值:實際值］、邏輯掃描碎片。
TABLERESULTS選項將用行集的形式顯示信息，將返回擴展盤區開關數、掃描密度［最佳值:實際值］、邏輯掃描碎片、擴展盤區掃描碎片、每頁上的平均可用位元組數、平均頁密度（完整）。
如果既指定FAST選項又指定TABLERESULTS選項，那麼將返回對象名、對象ID、索引名、索引ID，頁數、擴展盤區開關數、掃描密度［最佳值:實際值］和邏輯掃描碎片。
ALL_INDEXES選項將顯示指定表和試圖的所有索引的結果，即使指定了一個索引。
ALL_LEVELS選項指定是否為所處理的每個索引的每個級別產生輸出（默認只輸出索引的頁級或表數據級的結果），並且只能與 TABLERESULTS 選項一起使用。
解決碎片問題
一旦你確定表或索引有碎片問題，那麼你有4個選擇去解決那些問題：
刪除並重建索引
使用DROP_EXISTING子句重建索引
執行DBCC DBREINDEX
執行DBCC INDEXDEFRAG
盡管每一個技術都能達到你整理索引碎片的最終目的，但各有各的優缺點。
刪除並重建索引
用DROP INDEX和CREATE INDEX或ALTER TABLE來 刪除並重建索引有些缺陷包括在刪除重建期間索引會消失。在索引刪除重建時，對於查詢它不在可用，查詢性能也許會受到明顯的影響，直到重建索引為止。另一個 潛在的缺陷是當都請求索引的時候會引起阻塞，直到重建索引為止。通過其他的處理也能解決阻塞，就是索引被使用的時候不刪除索引。另一個主要的缺陷是在用DROP INDEX和CREATE INDEX重建聚集索引時會引起非聚集索引重建兩次。刪除聚集索引時非聚集索引的行指針會指向數據堆，聚集索引重建時非聚集索引的行指針又會指回聚集索引的行位置。
刪除並重建索引的確有一個好處就是通過重新排序索引頁，使索引頁緊湊並刪除不需要的索引頁來完全重建索引。你也許需要考慮那些內部和外部碎片都很高的情況下才使用，以使那些索引回到它們應該在的位置。
使用DROP_EXISTING子句重建索引
為了避免在重建聚集索引時表上的非聚集索引重建兩次，可以使用帶DROP_EXISTING子句的CREATE INDEX語句。這個子句會保留聚集索引鍵值，以避免非聚集索引重建兩次。和刪除並重建索引一樣，該方法也可能會引起阻塞和索引消失的問題。該方法的另一個缺陷是也強迫你去分別發現和修復表上的每一個索引。 除了和上一個方法一樣的好處之外，該方法的好處是不必重建非聚集索引兩次。這樣可以對那些帶約束的索引提供正確的索引定義以符合約束的要求。 執行DBCC DBREINDEX DBCC DBREINDEX類似於第二種方法，但它物理地重建索引，允許SQLServer給索引分配新頁來減少內部和外部碎片。DBCC DBREINDEX也能動態的重建帶約束的索引，不象第二種方法。 DBCC DBREINDEX的缺陷是會遇到或引起阻塞問題。DBCC DBREINDEX是作為一個事務來運行的，所以如果在完成之前中斷了，那麼你會丟失所有已經執行過的碎片。 執行DBCC INDEXDEFRAG DBCC INDEXDEFRAG（在SQLServer2000中可用）按照索引鍵的邏輯順序，通過重新整理索引里存在的葉頁來減少外部碎片，通過壓縮索引頁里的行然後刪除那些由此產生的不需要的頁來減少內部碎片。它不會遇到阻塞問題但它的結果沒有其他幾個方法徹底。這是因為DBCC INDEXDEFRAG跳過了鎖定的頁且不使用任何新頁來重新排序索引。如果索引的碎片數量大的話你也許會發現DBCC INDEXDEFRAG比重建索引花費的時間更長。DBCC INDEXDEFRAG比其他方法的確有好處的是在其他過程訪問索引時也能進行碎片整理，不會引起其他方法的阻塞問題。
③ 關於SQLSERVER的索引
這要看你的數據如何規劃，訪問時主要以什麼方式。
如果主要是以varchar列進行查詢，就按varchar列建立聚集索引，按int列建立非聚集索引。
如果主要是按int列進行排序查詢，就按int列建立聚集索引，按varchar列建立非聚集索引。
（注意上面說的int列不是主鍵，是你用來排序的列。）
配置資料庫索引是門很高深的學問，有興趣的話可以多搜索下相關資料。我都只是一知半解呢：）
④ SqlServer：索引是什麼，以及為什麼使用索引
收藏
問題反饋
索引
索引，使用索引可快速訪問資料庫表中的特定信息。索引是對資料庫表中一列或多列的值進行排序的一種結構。 在關系資料庫中，索引是一種與表有關的資料庫結構，它可以使對應於表的SQL語句執行得更快。索引的作用相當於圖書的目錄，可以根據目錄中的頁碼快速找到所需的內容。當表中有大量記錄時，若要對表進行查詢，第一種搜索信息方式是全表搜索，是將所有記錄一一取出，和查詢條件進行一一對比，然後返回滿足條件的記錄，這樣做會消耗大量資料庫系統時間，並造成大量磁碟I/O操作；第二種就是在表中建立索引，然後在索引中找到符合查詢條件的索引值，最後通過保存在索引中的ROWID（相當於頁碼）快速找到表中對應的記錄。 索引是一個單獨的、物理的資料庫結構，它是某個表中一列或若干列值的集合和相應的指向表中物理標識這些值的數據頁的邏輯指針清單。 索引提供指向存儲在表的指定列中的數據值的指針，然後根據您指定的排序順序對這些指針排序。資料庫使用索引的方式與您使用書籍中的索引的方式很相似：它搜索索引以找到特定值，然後順指針找到包含該值的行。 在資料庫關系圖中，可以在選定表的「索引/鍵」屬性頁中創建、編輯或刪除每個索引類型。當保存索引所附加到的表，或保存該表所在的關系圖時，索引將保存在資料庫中。
⑤ sqlserver如何壓縮數據文件空間
在程序組中，展開「Sqlserver」運行「查詢分析器」。輸入用戶名、密碼。
⑥ sqlserver 索引
索引和主鍵有什麼關系：主鍵是唯一且非空欄位，且主鍵本身就是個索引，所以無需對主鍵欄位再建索引
select * from 表名 這樣的語句用不到索引，索引其實類似於書的目錄，你要查的是整個表，所以這目錄就起不到作用
select * from 表名 where 欄位 = 條件 如果這時候這個欄位上有索引，這時一般是會用到索引的，就像你要從一本書中找某個內容，翻目錄找到對應的頁號，直接翻到這頁就可以了
select * from 表名 order by 欄位 如果這個欄位是有索引的，那麼會用這個索引來查找數據，因為按索引查詢會比冒泡類演算法效率高（沒索引的情況下，就是把整表數據取出來，然後用冒泡類演算法排除順序的）
表格設置索引了和沒設置索引查詢的效率會有不同么？：
查詢效率的不同主要就是資料庫系統分析你的sql語句後定出的執行路徑，如果這個執行路徑可以用到你建的索引，那麼基本上效率就會比全表掃描來的快
還是那個舉例，一本書，有目錄頁，你查東西的時候是塊了還是慢了？
⑦ SQLSERVER壓縮數據文件的用處有多大
本人的解決思路：
本人在想如果是這樣，到時候就收縮資料庫唄
在網上查了一下資料：由於DBCC SHRINKDATABASE一次運行會同時影響所有的文件（包括數據文件和日誌文件），使用者不能
指定每個文件的目標大小，其結果可能不能達到預期的要求。所以建議先做好規劃，對每個文件確定預期目標，然後使用DBCC SHRINKFILE
來一個文件一個文件地做比較穩妥
本來很開心的，網上資料都說使用DBCC SHRINKFILE來收縮文件，那這樣就不怕拉 （我不怕不怕拉~）
但是，往下看那個資料：
1、首先了解數據文件當前的使用情況
收縮量的大小不可能超過當前文件的空閑空間的大小。如果想要壓縮資料庫的大小，首先要確認數據文件里的確有相應未被使用的空間。如果空間都在
使用中，那就要確認大量佔用空間的對象（表格或索引）。然後通過歸檔歷史數據，先把空間釋放出來
2、主數據文件（primary file）是不能被清空的。能被完全清空的只有輔助數據文件
3、如果要把一個文件組整個清空，要刪除分配在這個文件組上的對象（表格或索引），或者把他們移到其他文件組上。
DBCC SHRINKFILE不會幫你做這個工作
把數據文件裡面數據和對象清除完、確認數據文件（組）有足夠的空閑空間後，管理員就可以使用DBCC SHRINKFILE來縮小或清空指定文件了。
如果要縮小文件，就填上需要的target_size，如果要清空文件，就選擇EMPTYFILE
根據上面資料所說，本人的解決思路是：
1、確認大量佔用空間的對象（表格或索引）。然後通過歸檔歷史數據，先把空間釋放出來再壓縮數據文件
2、重建索引，把一些數據頁面重排一次，原先的頁面被釋放，所佔用的分區也被釋放，再去DBCC SHRINKFILE
⑧ 為什麼說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*」』這樣的條件查詢，上面那條記錄是不會被返回的。它的分詞應該是正向最大值的分詞方法，它沒有對方向再進行一次分詞和索引，索引無法查詢到。這個可能會被大家所忽略掉的。
⑨ 如何檢查sql資料庫索引填充因子是否產生碎片以及如何處理
這是收藏的一些資料：
SQLServer提供了一個資料庫命令――DBCC SHOWCONTIG――來確定一個指定的表或索引是否有碎片。
示例：
顯示資料庫里所有索引的碎片信息
DBCC SHOWCONTIG WITH ALL_INDEXES
顯示指定表的所有索引的碎片信息
DBCC SHOWCONTIG (authors) WITH ALL_INDEXES
顯示指定索引的碎片信息
DBCC SHOWCONTIG (authors,aunmind)
DBCC 執行結果：
掃描頁數：如果你知道行的近似尺寸和表或索引里的行數，那麼你可以估計出索引里的頁數。看看掃描頁數，如果明顯比你估計的頁數要高，說明存在內部碎片。
掃描擴展盤區數：用掃描頁數除以8,四捨五入到下一個最高值。該值應該和DBCC SHOWCONTIG返回的掃描擴展盤區數一致。如果DBCC SHOWCONTIG返回的數高，說明存在外部碎片。碎片的嚴重程度依賴於剛才顯示的值比估計值高多少。
擴展盤區開關數：該數應該等於掃描擴展盤區數減1。高了則說明有外部碎片。
每個擴展盤區上的平均頁數：該數是掃描頁數除以掃描擴展盤區數，一般是8。小於8說明有外部碎片。
掃描密度［最佳值:實際值］：DBCC SHOWCONTIG返回最有用的一個百分比。這是擴展盤區的最佳值和實際值的比率。該百分比應該盡可能靠近100％。低了則說明有外部碎片。
邏輯掃描碎片：無序頁的百分比。該百分比應該在0％到10％之間，高了則說明有外部碎片。
擴展盤區掃描碎片：無序擴展盤區在掃描索引葉級頁中所佔的百分比。該百分比應該是0％，高了則說明有外部碎片。
每頁上的平均可用位元組數：所掃描的頁上的平均可用位元組數。越高說明有內部碎片，不過在你用這個數字決定是否有內部碎片之前，應該考慮fill factor（填充因子）。
平均頁密度（完整）：每頁上的平均可用位元組數的百分比的相反數。低的百分比說明有內部碎片。
解決碎片問題 ：
1. 刪除並重建索引
2. 使用DROP_EXISTING子句重建索引
3. 執行DBCC DBREINDEX
4. 執行DBCC INDEXDEFRAG
刪除並重建索引 ：
用DROP INDEX和CREATE INDEX或ALTER TABLE來刪除並重建索引有些缺陷包括在刪除重建期間索引會消失。在索引刪除重建時，對於查詢它不在可用，查詢性能也許會受到明顯的影響，直到重建索引為止。另一個潛在的缺陷是當都請求索引的時候會引起阻塞，直到重建索引為止。通過其他的處理也能解決阻塞，就是索引被使用的時候不刪除索引。另一個主要的缺陷是在用DROP INDEX和CREATE INDEX重建聚集索引時會引起非聚集索引重建兩次。刪除聚集索引時非聚集索引的行指針會指向數據堆，聚集索引重建時非聚集索引的行指針又會指回聚集索引的行位置。
刪除並重建索引的確有一個好處就是通過重新排序索引頁，使索引頁緊湊並刪除不需要的索引頁來完全重建索引。你也許需要考慮那些內部和外部碎片都很高的情況下才使用，以使那些索引回到它們應該在的位置。
使用DROP_EXISTING子句重建索引 ：
為了避免在重建聚集索引時表上的非聚集索引重建兩次，可以使用帶DROP_EXISTING子句的CREATE INDEX語句。這個子句會保留聚集索引鍵值，以避免非聚集索引重建兩次。和刪除並重建索引一樣，該方法也可能會引起阻塞和索引消失的問題。該方法的另一個缺陷是也強迫你去分別發現和修復表上的每一個索引。
除了和上一個方法一樣的好處之外，該方法的好處是不必重建非聚集索引兩次。這樣可以對那些帶約束的索引提供正確的索引定義以符合約束的要求。
執行DBCC DBREINDEX ：
DBCC DBREINDEX類似於第二種方法，但它物理地重建索引，允許SQLServer給索引分配新頁來減少內部和外部碎片。DBCC DBREINDEX也能動態的重建帶約束的索引，不象第二種方法。
DBCC DBREINDEX的缺陷是會遇到或引起阻塞問題。DBCC DBREINDEX是作為一個事務來運行的，所以如果在完成之前中斷了，那麼你會丟失所有已經執行過的碎片。
執行DBCC INDEXDEFRAG ：
DBCC INDEXDEFRAG（在SQLServer2000中可用）按照索引鍵的邏輯順序，通過重新整理索引里存在的葉頁來減少外部碎片，通過壓縮索引頁里的行然後刪除那些由此產生的不需要的頁來減少內部碎片。它不會遇到阻塞問題但它的結果沒有其他幾個方法徹底。這是因為DBCC INDEXDEFRAG跳過了鎖定的頁且不使用任何新頁來重新排序索引。如果索引的碎片數量大的話你也許會發現DBCC INDEXDEFRAG比重建索引花費的時間更長。DBCC INDEXDEFRAG比其他方法的確有好處的是在其他過程訪問索引時也能進行碎片整理，不會引起其他方法的阻塞問題。