1. 首頁
  2. 問答
  3. 在SQL Server 2005中沒有聚集索引的原因

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

2010-10-27 78 views
8

我已經繼承了SQL SERVER 2005數據庫的一些數據庫創建腳本。在SQL Server 2005中沒有聚集索引的原因

我注意到的一件事情是，所有主鍵都創建爲NON CLUSTERED索引，而不是聚簇。

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

所以我的問題是有沒有任何技術原因除了上面的主鍵列上聚集索引。

來源

2010-10-27 AJM

+1

「我注意到的一件事是，所有的主鍵都創建爲非集羣索引，而不是clustured」爲什麼我觀察到相反？ – 2010-10-28 02:19:51

+0

@ vgv8 - 澄清，它是我繼承的數據庫腳本明確地將密鑰設置爲非羣集。 – AJM 2010-10-28 08:40:43

+1

我也仍然無法理解它http://stackoverflow.com/questions/3970430/why-when-how-is-whole-clustered-index-scan-chosen-rather-than-full-table-scan，雖然我不明白爲什麼/何時有聚集索引 – 2010-10-28 10:35:46

回答

8

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

像批量導入表或臨時表之類的東西 - 這取決於。

對一些人來說令人驚訝的是，似乎有一個好的聚集索引實際上可以加速像INSERT或UPDATE這樣的操作。請參閱Kimberly Tripps出色的The Clustered Index Debate continues....博客文章，其中她詳細解釋了爲什麼會出現這種情況。

有鑑於此：我沒有看到任何有效原因不有一個良好的聚集索引（窄的，穩定的，獨特的，不斷增加= INT IDENTITY是最明顯的選擇）上的任何SQL Server表。

爲了得到一些深刻的見解如何以及爲什麼要選擇集羣鍵，讀取所有金佰利特里普的優秀博客文章的題目是從「皇后

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

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

優秀的東西索引「！:-)

來源

2010-10-27 14:03:32

6

Clustered Tables vs Heap Tables

堆表（沒有聚集索引）

  • 數據不被存儲在任何特定的順序

    （在上主體www.mssqltips.com好文章）

  • 具體數據c一個不被檢索 很快，除非也有 非聚集索引

  • 數據頁沒有聯繫，所以 順序訪問需要重提 的索引分配映射（IAM）

  • 頁

    由於沒有聚簇索引， 額外的時間，不需要到 維護索引

  • 由於沒有聚簇索引， 有不TH E需求額外 空間來存儲聚集索引 樹

  • 這些表具有 0在sys.indexes目錄視圖

簇表一個index_id的值

  • 數據的存儲順序依據 聚簇索引鍵

    • 個

  • 數據可以快速檢索基於 聚集索引鍵，如果 查詢使用索引列

  • 數據頁鏈接更快 順序訪問，以保持聚集索引基於 其他需要時間 插入，更新和刪除操作

  • 是需要額外的空間來存儲 簇索引樹 這些表在sys.indexes目錄具有1的值index_id的查看

來源

2010-10-27 14:10:41 Branimir

1

請在「」下閱讀我的回答沒有直接訪問聚集表中的數據行 - 爲什麼？首先是。具體項目[2]警告。

創建「數據庫」的人是cretins。他們有：

  • unnormalised spreadhseets，沒有規範化的關係表的一堆
  • 的的PK 所有 IDENTITY列（電子表格鏈接到對方;他們要一個導航逐單由酮）;有跨數據庫沒有關係訪問或關係功率
  • 他們有PRIMARY KEY，從而產生獨特的羣集
  • 他們發現，防止併發
  • 他們刪除的CI，使它們都NCIS
  • 他們太懶惰完成逆轉;提名備用（電流NCI）成爲新的CI，每個表
  • IDENTITY列仍是主鍵（這是不是真的，但它在這個hamfisted實現）

對於這種僞裝成數據庫的電子表格集合，完全避免配置項變得越來越普遍，並且只有NCI和堆。很明顯，他們沒有獲得CI的權力或好處，但是他們沒有得到關係數據庫的力量或好處，所以誰在乎他們沒有獲得CI的權力（這是爲關係數據庫設計的，他們的不是）。他們看待它的方式，他們不得不每隔一段時間「重構」事物，所以爲什麼要麻煩。關係數據庫不需要「重構」。

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

來源

2010-10-29 13:39:56 PerformanceDBA

+0

10您能否提供任何有關「完全避免CI越來越常見」以及「CI的權力或好處」的參考？ – 2010-11-03 04:01:46

+1

@ vgv8：*如果您需要進一步討論此響應，請發佈CREATE TABLE/INDEX DDL;否則這是一個浪費時間的學術論證*你從過去的經驗中得知：MS很少有深入的信息，這就是爲什麼專家有自己的方法，爲什麼人們付錢給他們。試試Google。嘗試StackOverflow。我發現這[這個職位]（http://stackoverflow.com/questions/3336934/）這恰好部分地回答你的問題。有一天，我會寫一本書，然後你會有充分的參考。 – PerformanceDBA 2010-11-03 04:42:56

0

對於今天仍然使用的一些b-tree服務器/編程語言，固定或可變長度的扁平ascii文件用於存儲數據。當一個新的數據記錄/行被添加到一個文件（表）中時，該記錄被（1）追加到文件末尾（或者替換已刪除的記錄）和（2）索引被平衡。當以這種方式存儲數據時，您不必關心繫統性能（就b-tree服務器返回指向第一個數據記錄的指針而言）。響應時間僅受索引文件中節點數的影響。

當您開始使用SQL時，您希望在編寫SQL語句時意識到必須考慮系統性能。在非索引列上使用「ORDER BY」語句會使系統癱瘓。使用聚集索引可能會給CPU帶來不必要的負擔。這是21世紀，我希望在用SQL進行編程時不必考慮系統性能，但我們仍然這樣做。

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

在我25年的編程中，我從來不需要以特定順序存儲我的物理數據，所以也許這就是爲什麼有些程序員避免使用聚簇索引。很難知道什麼是折衷（存儲時間，取決於檢索時間），特別是如果您正在設計的系統可能有一天存儲數百萬條記錄。

來源

2016-06-09 00:11:37 mjb

相關問題

 相關問題