沒有一個觸及這個超過一個月。
前三個的答案實際上是在Diagram I Made for You，你沒有費心去消化和提出有關......的問題，它經常被用作討論的平臺。
（這是我的更精細的的Sybase圖，我已經屠殺了MS上下文的濃縮版。有一個在該文檔的底部的鏈接，如果你想充分的Sybase集）
因此，我不會花太多時間在你身上。請不要要求鏈接到「參考站點」，不存在這樣的事情（可用的是非技術性垃圾），這正是我擁有自己的圖表的原因;很少有人理解MS SQL內部知識。
回收的空間
這是正確的說法。 MS不會從頁面中刪除已刪除的行，或從範圍中刪除已刪除的頁面。回收空間是一種通過堆並刪除未使用的（a）行和（b）頁的操作。當然這會改變RowIds，所以所有非聚簇索引都必須重建。
壓縮
在所粘貼的文本的上下文中：同開墾空間。
碎片整理
完全去除水垢的未使用空間的操作。有三個層次：
一數據庫（AllocationUnits），在所有對象
II。對象（範圍&頁面），頁面鏈，分割頁面，溢出頁面
三。堆內（沒有聚集索引），後置
SHRINKFILE
完全不同的運營主體，以減少在設備上（文件）分配的空間。這將刪除未使用的AllocationUnits（因此爲'shrink'），但它不同於將AllocationUnits分解。
SHRINKDATABASE
爲數據庫做同樣的;所有設備的數據庫使用的所有設備分配。
迴應評論
的海報在SSC是無能，不直接解決您的問題。
- 有作爲聚集表沒有這樣的事情（創建聚集表失敗）
- 有這樣的事，作爲一個聚集索引（用於創建聚簇索引成功）
- 按我的圖，它是一個單一的物理結構;聚集索引包括行，因此堆被消除
- 那裏是沒有聚集索引，有兩個物理結構：一個堆和一個獨立的非聚集索引
現在你去潛水之前進入他們DBCC ，這是等級太低，而無能的人不能確定，更不用說解釋的理由和目的，你需要了解並確認以上：
- 創建Table_CI（我們打算增加一個CI，有仍然沒有像Clustered Table這樣的東西）
- 添加一個唯一的聚集索引，它UC_PK
添加幾行
創建一個表堆
- 添加一個唯一的非聚集索引，它NC_PK
添加幾行
SELECT * FROM sysindexes WHERE id = OBJECT_ID（「Table_CI」）
SELECT * FROM sysindexes WHERE id = O BJECT_ID（「堆」）
注意，每個sysindexes中的條目是一個完整的，獨立的數據存儲結構（看看列）
- 考慮輸出
- 我的圖比較
- 與比較在宇宙垃圾
今後，我不會回答關於宇宙的困惑垃圾，以及其他網站上不正確的和誤導的職位問題（我不在乎，如果他們一他們已經證明他們不能檢查他們的數據庫並確定正確的信息）
有一個原因，我打擾創建準確的圖表（手冊，圖片和所有可用的信息來自MS ，都是垃圾;沒有必要從你的權威機構尋找準確的信息「，因爲」權威「在技術上已經破產）。
即使蓋爾終於得到 我懷疑你會受益於更多的閱讀索引的整體架構之前擺脫低級內部。
除了沒有。這不是混淆，非技術性和不一致的。
有一個原因，我打擾創建準確的圖表。
返回到DBCC。蓋爾簡直是錯誤的。在集羣索引（包含行）中，單個頁面包含行。是的，行。那就是指數的葉級。有一棵B樹，它生活在頁面的頂部，但它很小，你看不到它。查看sysindexes輸出。根和第一頁指針指向頁面;這是聚集索引的根源。當你潛入大海時，你需要知道要尋找什麼，以及在哪裏找到它，否則你將無法找到你正在尋找的東西，並且你會因爲偶然發現的漂浮物和噴氣式遊艇而分心。
現在看看NCI和堆的兩個單獨結構。
哦，MS已經從使用OAM術語改變爲IAM，其中數據結構是索引。這引起了混淆。在數據結構（sysindexes中的條目）方面，它們都是對象;他們可能或可能不是指數）。關鍵是，誰在乎，我們知道它是什麼，它是一個ObjectAllocationMap ...如果你在NCI看，gee，它是一個IndexObjectAllocationMap;如果您正在查看堆，它是一個HeapObjectAllocMap。我會讓你思考一下CI的情況。在追逐它或者使用它時（找到屬於OBJECT的頁面並不重要，它們都是對象，當你這樣做的時候，你需要知道，一些對象有一個PageChain，其他的對象沒有（另一個。你的問題）：順有他們; NCIS和堆不
蓋爾肖：「我懷疑這些類型的內部被記錄任何地方，畢竟我們使用無證功能指標的定義取決於誰你問。和你在哪裏看。
ROTFLMAO。我的身體受到傷害，我無法閱讀後面的帖子。這些應該是聰明的人類？在IT世界工作嗎？定義CHANGE？溫度或溫度一天中的時間？那就是SQL Server Central ？不是後山？
當MS從Sybase處盜取SQL Server時，文檔非常穩定。對於每個主要版本，coure，他們「重寫」它，文檔變得更弱，更蓬鬆（回憶我們在另一篇文章中的討論）。現在，我們有可愛的照片，讓人感覺良好，但技術上不準確。這就是爲什麼像你這樣認真的人有問題。圖片甚至不符合手冊中的文字。
無論如何，定義不會改變。這就是定義的定義。在任何情況下都是如此。嗯，你使用的這個功能是一個普通的，記錄在案的功能。自從1987年以來，除了MS失去了它，沒有人能找到它。您將不得不詢問一位在過去幾乎一直存在的Sybase Guru，他們記得他們獲得的代碼中確切的數據結構。如果你真的很幸運，他會跟上MoronSociety在2000年，2005年，2008年推出的差異。他甚至可能有一個精確的圖表，可以與你的盒子上的sysindexes和DBCC的輸出相匹配。如果你找到他，親吻他的戒指，用金子給他洗澡。鎖定你的女兒。
（不嚴重，我的雙方正在殺死我，歡樂溢出）。
現在你明白了爲什麼我不會回答關於宇宙中的混淆垃圾的問題嗎？在MoronSociety中有很多這樣的白癡。
-----
再次蓋爾：
「掃描：
索引掃描是所有索引的葉級頁的完整讀取當索引掃描。在聚簇索引上完成，這是一個表掃描，除了名稱。
當索引掃描由查詢處理器完成時，它始終是索引中所有葉頁的完整讀取，無論是否全部的行被返回。這是neve r部分掃描。
的掃描不僅涉及讀取索引的葉級，更高級別的網頁也被解讀爲索引掃描的一部分。」
必須有一個原因，她正在迅速風的名字命名的。她寫道： 「書」嗎？是的，幻想小說。熱空氣是爲氣球專家而不是IT專業人員。
完整和完整的drivel。索引掃描的全部和爲什麼它可以預先掃描一個表掃描，因爲它試圖避免一個表掃描，是： - 引擎（執行查詢樹）可以直接進入索引（集羣或非集羣，在這一點） - 導航B樹找到開始的地方（哪直到這一點，與獲得幾行時的情況大致相同，即。沒有掃描） - B樹（從任何好的技術圖）是幾頁，每頁包含許多，很多索引條目，所以它非常快 - 這是根加非葉級 - 直到它找到葉級條目資格 - 就從這一點來說，它的掃描，依次通過的葉級表示指數（脂肪藍色箭頭）
沒有跳躍爲了比較的話，表掃描（僅MS）： - 對堆 沒有PageChain - 別無選擇，但從頭開始 - 並讀取每個數據頁面 - 其中許多將被分割（包含被刪除或轉發的行留下未使用的空間） - 其他將完全爲空
整體意圖是，優化程序已經決定不去表（堆）掃描，它可以進行索引掃描（因爲它需要比全部數據少的LESS，並且可以通過某個索引找到該數據的起始點）。如果你看看你的SHOWPLAN，即使是檢索一個唯一的PK行，它也會顯示「INDEX SCAN」。所有這一切意味着，它將首先瀏覽B-Tree，找到至少一行。然後它可以掃描葉級，直到找到一個終點。如果它是一個覆蓋的查詢，它永遠不會進入數據行。
集羣索引無法替代。
這屬於www.serverfault.com因爲它是管理相關的，而不是編程。 – 2010-09-29 21:09:26
對您的更新添加了回覆。 – PerformanceDBA 2010-11-06 05:31:42