簡體 English 中英

SQL Server 2005中沒有聚簇索引的原因

[英]Reasons not to have a clustered index in SQL Server 2005

原文 2010-10-27 14:00:48 1 5 sql-server/ sql-server-2005/ tsql/ indexing/ clustered-index

我為SQL SERVER 2005數據庫繼承了一些數據庫創建腳本。

我注意到的一件事是，所有主鍵都是作為NON CLUSTERED索引而不是群集創建的。

我知道每個表只能有一個聚簇索引，並且您可能希望將它放在非主鍵列上以查詢搜索性能等。但是問題中的表中沒有其他CLUSTERED索引。

所以我的問題是，除了上述之外，是否有任何技術原因不在主鍵列上有聚簇索引。

5 個解決方案

在任何“正常”數據或查找表上：不，我沒有看到任何理由。

在諸如批量導入表或臨時表之類的東西上 - 這取決於。

令人驚訝的是，看起來擁有良好的聚簇索引實際上可以加快INSERT或UPDATE等操作。 請參閱Kimberly Tripps優秀的Clustered Index辯論繼續....博客文章中她非常詳細地解釋了為什么會這樣。

有鑒於此：我認為沒有任何正當理由不在任何SQL Server表上擁有良好的聚簇索引（窄，穩定，唯一，不斷增加= INT IDENTITY作為最明顯的選擇）。

要深入了解如何以及為何選擇群集密鑰，請閱讀Kimberly Tripp關於該主題的所有優秀博文：

http://www.sqlskills.com/BLOGS/KIMBERLY/category/Clustering-Key.aspx

http://www.sqlskills.com/BLOGS/KIMBERLY/category/Clustered-Index.aspx

來自“索引女王”的優秀作品！ :-)

集群表與堆表

（關於主題的好文章，請訪問www.mssqltips.com ）

HEAP表（沒有聚簇索引）

數據不以任何特定順序存儲
除非還有非聚集索引，否則無法快速檢索特定數據
數據頁未鏈接，因此順序訪問需要返回索引分配映射（IAM）頁面
由於沒有聚簇索引，因此不需要額外的時間來維護索引
由於沒有聚簇索引，因此不需要額外的空間來存儲聚簇索引樹
這些表在sys.indexes目錄視圖中的index_id值為0

集群表

數據基於聚簇索引鍵按順序存儲
如果查詢使用索引列，則可以基於聚簇索引鍵快速檢索數據
鏈接數據頁以加快順序訪問需要額外的時間來維護基於INSERTS，UPDATES和DELETES的聚簇索引
存儲聚簇索引樹需要額外的空間這些表在sys.indexes目錄視圖中的index_id值為1

請閱讀我的答案“ 無法直接訪問集群表中的數據行 - 為什么？” ，首先。 具體項目[2]警告。

創建“數據庫”的人是cretins。 他們有：

一堆非規范化的spreadhseets，而不是規范化的關系表
的PKS 都是 IDENTITY列（電子表格鏈接到彼此;它們必須被導航一個接一個接一個）; 數據庫中沒有關系訪問或關系功能
他們有PRIMARY KEY，它產生了獨特的聚集
他們發現這阻止了並發性
他們刪除了CI並使他們成為所有NCI
他們懶得完成逆轉; 為每個表提名一個備用（當前NCI）成為新的CI
IDENTITY列仍然是主鍵（它不是真的，但它在這個hamfisted實現中）

對於偽裝成數據庫的電子表格集合，完全避免CI會變得越來越普遍，並且只有NCI和堆。 顯然他們沒有得到CI的權力或好處，但是他們沒有得到關系數據庫的權力或好處，所以誰關心他們沒有得到CI的力量（這是為關系數據庫設計的，他們的不是）。 他們看待它的方式，無論如何都要經常“重構”這些糟糕的事情，所以為什么要費心呢。 關系數據庫不需要“重構”。

如果您需要進一步討論此響應，請發布CREATE TABLE / INDEX DDL; 否則這是浪費時間的學術論點。

對於目前仍在使用的一些b樹服務器/編程語言，固定或可變長度的平坦ascii文件用於存儲數據。 將新數據記錄/行添加到文件（表）時，記錄將（1）附加到文件末尾（或替換已刪除的記錄）和（2）索引是平衡的。 以這種方式存儲數據時，您不必擔心系統性能（就b-tree服務器執行的操作而言，返回指向第一個數據記錄的指針）。 響應時間僅受索引文件中的節點數的影響。

當您開始使用SQL時，您希望每當編寫SQL語句時都必須考慮系統性能。 在非索引列上使用“ORDER BY”語句可以使系統癱瘓。 使用聚簇索引可能會給CPU帶來不必要的負載。 這是21世紀，我希望在SQL編程時不必考慮系統性能，但我們仍然這樣做。

對於一些較舊的編程語言，每當檢索到排序數據時都必須使用索引。 我只希望今天這個要求仍然存在。 我只能想知道有多少公司更新了他們的慢速計算機系統，因為在非索引數據上寫的SQL語句寫得不好。

在我25年的編程中，我從未需要以特定順序存儲我的物理數據，因此這可能是一些程序員避免使用聚簇索引的原因。 很難知道權衡是什么（存儲時間，檢索時間），特別是如果您正在設計的系統有一天可能存儲數百萬條記錄。

這是另一個（已經在其他答案中提供過嗎？）可能的原因（仍有待理解）：