我在理解聚集索引時錯過了什麼？

Question

在沒有錶行通過IAM（（索引分配映射表）。訪問的任何指數的
我可以以編程方式使用IAM直接訪問行？

確實沒有索引的意思是隻有這樣，才能具體閱讀行全表掃描讀取所有的表？
爲什麼IAM不能從事更具體直接訪問？

「如果表是一個堆（換句話說，它沒有聚集索引），書籤是行標識符（RID），它是File形式的實際行定位符＃：Page＃：Slot＃「[1a]

slot沒有進一步的定義。那麼其他的消息來源表明Slot＃真的是行號。正確？還是需要與IAM進一步並置來確定特定行？

現在，引入聚簇索引意味着不能直接訪問數據，只能通過最終聚簇索引查找或按順序遍歷聚簇葉節點。

我是否正確理解聚簇索引的引入僅對選擇連續的相鄰（範圍）行和僅通過聚簇索引鍵有利？
聚類表有哪些好處？

我是否正確理解聚集索引引入會加劇非聚集索引參與非精確匹配查詢的性能優勢？沒有直接訪問，順序訪問不能並行化，非聚集索引通過聚簇索引鍵等增加，是正確的？

嗯，我看到聚集一張表對於非常具體而且很好理解的上下文是有意義的，而主鍵的創建總是默認在聚集表中。爲什麼？

聚簇索引理解中我錯過了什麼？

[1]
裏面微軟的SQL Server™2005：存儲引擎
通過卡倫·德萊尼 - （質堅實學習）
................. ..............................
出版商：Microsoft Press
Pub日期：2006年10月11日
打印ISBN- 10：0-7356-2105-5
印刷ISBN-13：978-0-7356-2105-3
頁數：464

[1a]第250章科索引組織來自第7章。指數內幕和管理

這裏是有用的在線copypaste從中
http://sqlserverindexeorgnization.blogspot.com/
雖然沒有任何學分源

相關的問題：

• No direct access to data row in clustered table - why?
• Why/when/how is whole clustered index scan chosen rather than full table scan?
• Reasons not to have a clustered index in SQL Server 2005

---

更新： @PerformanceDBA，

• 「請忘記你DOCO參考，並再次啓動」

什麼樣的基礎上，又開始了我？
任何引用，任何建議。技巧如何重新開始？

• **「聚集索引始終是更好」

你能回答我的問題Why/when/how is whole clustered index scan chosen rather than full table scan?的疑問是什麼，是完全聚集索引掃描的意思。它讀取的不是全表掃描嗎？

• 「」如果有IAM，那麼沒有索引」

所以，沒有IAM，如果沒有索引呢？
有IAM如果有CI？

我怎麼驗證/研究它
如果所有文檔寫相反：
- 有IAM在非索引表
- 沒有IAM如果出現聚集IND恩。

Answer 1

這是很多問題。是的，IAM用於在堆上查找頁面。區別在於，如果沒有索引，就無法知道對於任何給定數據片段要檢索哪些頁面。 SQL /關係數據模型的一個重要特徵是查詢只能通過數據值訪問數據 - 而不是直接使用指針或其他結構。

槽號只是標識頁面內的一行。行數據在頁面內不是邏輯排序的，即使在聚簇索引中也是如此。每個數據頁面都包含一個指向頁面內行的位置的行偏移表。

由於需要額外的書籤查找，聚集索引可能會減慢非聚簇索引的數據訪問速度。這可以通過使用INCLUDE子句將列添加到NC索引來緩解。有時，在表上沒有聚簇索引可能更有效。

Answer 2

請閱讀我的回答根據「沒有直接訪問聚集表中的數據行 - 爲什麼？「，第一。

如果有IAM，然後有一個指數。

但是，如果沒有CI，則該行是在一個堆，是的，如果你想直接讀取（沒有使用NCI，或者沒有指數存在的地方），你只能對錶進行堆掃描

聚集索引總是更好，沒有一個，有一個例外和一個警告， - 標準條件：

1. 非唯一CI密鑰Th導致溢出頁面。關係表必須具有唯一鍵，所以這不是關係表。通過重載列可以使CI很容易變得獨特。一個非唯一的配置文件仍然更好（根據我的其他職位），以使非獨特的配置文件比沒有配置項。

2. 單調的關鍵。通常是一個IDENTITY列。插入行分佈在整個數據存儲結構中的隨機插入（而不是隨機的插入）（正常情況下具有「良好」的自然關係密鑰），插入的密鑰始終位於最後一頁。這會導致插入熱點，並降低併發性。關係密鑰應該是自然唯一的;替代項是總是一個額外的索引。代理只是一個關係表（它是一組非規範化的電子表格，其中的行標識符將它們鏈接在一起;您不會從數據庫中獲得數據庫的表現力）。 。
   所以常見的建議是，使用NCI作爲單調密鑰，並確保CI允許良好的數據分佈。

負債證明書的優勢是巨大的，沒有很好的理由，有一個（有可能是如上面提到的不好的原因）。

配置項允許範圍查詢; NCI不會。但這不是唯一的原因。

另一個需要注意的是，你需要保持CI重點小的寬度，因爲它是在NCIS攜帶。現在通常這不是一個問題，因爲寬CI鍵很好。但是，如果您的電子表格僞裝成數據庫的Unormalise dbunch會導致比標準化數據庫更多的索引，這確實成爲一個考慮因素。因此帝國奉獻者的忠告是保持CI鍵的寬度。配置項不會「增加」NCI，這是不準確的。如果你有NCI，那麼它會有一個指針或一個CI密鑰;如果你有一個CI（具有所有的好處），那麼成本是CI密鑰而不是RowId，可以忽略不計。所以準確的說法是，增加NCIs。

誰說的CI的順序訪問不能並行化是錯誤的（MS可以打破它的一個版本，並在接下來的修復它，但這是短暫的）。

使用ANSI SQL ... PRIMARY KEY ...符號默認爲唯一的聚集。因爲db應該是Relational。獨特的PK應該是一個很好的友好的關係密鑰，而不是一個白癡的IDENTITY列。因此總是（不包括例外）PRIMARY KEY是聚類的最佳候選者。

你總是可以創造任何你想要的指數通過避免ANSI SQL ... PRIMARY KEY ...符號和使用CREATE [UNIQUE] [CLUSTERED]索引符號來代替。

這是不可能回答你的最後一個問題，你必須不斷地問問題，直到你用完。但是，請你忘記你提到的可可，並重新開始，否則我們會在這裏討論明確的知識和gobbledegook之間的區別。