Clustered vs NonClustered主鍵

begin transaction; 
create table person_id(person_id integer primary key); 
insert into person_id values(1); 
... snip ... 
insert into person_id values(50000); 
commit;

此代碼在我的機器上大約需要0.9秒，並創建一個佔用392K的db文件。這些數字成爲約1.4秒864K，如果我改變第二行Clustered vs NonClustered主鍵

create table person_id(person_id integer nonclustered primary key);

爲什麼會出現這種情況？

來源

2010-01-26 Elite Mx

[只作爲一種思想]

也許當你明確指定取整數列作爲聚集鍵，它做到了這一點。但是當你告訴它不要使用你的整數列時，它仍然會在幕後創建一個索引，但爲此選擇一個不同的數據類型，假設是兩倍。然後，每個條目都必須引用表格中的記錄，然後在這裏，大小正在爆炸。

來源

2010-01-26 09:48:35

將主鍵集羣存儲在行中;這意味着它佔用更少的空間（因爲沒有單獨的索引塊）。但是，通常它的主要優點是範圍掃描通常可以訪問同一個塊中的行，從而減少IO操作，當您有大量數據集時（而不是50k整數），這將變得非常重要。

我認爲50k整數是一個相當虛假的基準，而不是你在現實世界中關心的人。

來源

2010-01-26 09:53:51 MarkR

如果我沒做連接，也不範圍掃描計劃，只關心插入性能 - 會不會有什麼更好的方式來創建表比第一個例子？ – 2010-01-26 09:56:23

如果您只關心插入性能，則根本不應使用索引（如果支持），或將數據寫入文本文件。附加到文本文件非常快。 – MarkR 2010-01-26 21:49:35

我隨機化插入語句，並重新做了查詢與從一到五十萬的值。有趣的是，集羣和非集羣數據庫文件現在都佔用了精確的空間量（直到字節）。但是，羣集數據庫中的插入仍然更快。

對我來說，這是違反直覺的。當我告訴數據庫集羣這些值 - 我告訴數據庫......當我回來獲取它們時，這些值更好地按照這個順序排列。當我沒有這個規範時，我基本上是在說db - 看看這些價值觀，然後按照你的喜好來安排它們 - 無論如何讓你的生活更輕鬆。

理論上，這種額外的自由度決不應該減慢查詢速度。也許不會一直加速它們，但從不放慢速度。思考？

來源

2010-01-26 17:30:18

一個偉大的回答這個問題，請在以DBA StackExchange：https://dba.stackexchange.com/questions/7741/when-should-a-primary-key-be-declared-non-clustered/7744#7744

來源

2013-03-12 01:57:23

Clustered vs NonClustered主鍵

回答

相關問題