В таблица без клъстерен индекс (таблица с купчина) страниците с данни не са свързани помежду си - така че преминаването на страници изисква търсене в картата за разпределение на индекс .
Клъстерираната таблица обаче има своите страници с данни, свързани в двойно свързан списък - правене на последователни сканирания малко по-бързи. Разбира се, в замяна имате режийните разходи за поддържане на страниците с данни в ред на INSERT , UPDATE и DELETE . Въпреки това, таблицата с купчина изисква втори запис в IAM.
Ако вашата заявка има RANGE оператор (напр.:SELECT * FROM TABLE WHERE Id BETWEEN 1 AND 100 ), тогава една клъстерирана таблица (която е в гарантиран ред) би била по-ефективна - тъй като може да използва индексните страници, за да намери съответната страница(и) с данни. Купчината ще трябва да сканира всички редове, тъй като не може да разчита на подреждане.
И, разбира се, клъстериран индекс ви позволява да правите КЛУСТЕРИРАНО ТЪРСЕНЕ НА ИНДЕКС, което е доста оптимално за производителност...купчина без индекси винаги ще доведе до сканиране на таблица.
И така:
-
За вашата примерна заявка, при която избирате всички редове, единствената разлика е двойно свързаният списък, поддържан от клъстерен индекс. Това би трябвало да направи вашата клъстерирана таблица малко по-бърза от купчина с голям брой редове.
-
За заявка с
WHEREклауза, която може да бъде (поне частично) удовлетворена от клъстерирания индекс, ще излезете напред поради подреждането - така че няма да се налага да сканирате цялата таблица. -
За заявка, която не е удовлетворена от клъстерирания индекс, вие сте почти изравнени... отново, единствената разлика е този двойно свързан списък за последователно сканиране. И в двата случая не сте оптимален.
-
За
INSERT,UPDATEиDELETEкупчина може или не може да спечели. Купчината не трябва да поддържа ред, но изисква втори запис в IAM. Мисля, че относителната разлика в производителността би била незначителна, но също така доста зависима от данните.
Microsoft има бяла книга който сравнява клъстерен индекс с еквивалентен не-клъстерен индекс на купчина (не точно същото, както обсъдих по-горе, но близко). Техният извод е основно да се постави клъстерен индекс на всички таблици. Ще направя всичко по силите си, за да обобщя техните резултати (отново имайте предвид, че те наистина сравняват неклъстерен индекс с клъстерен индекс тук - но мисля, че е относително сравним):
INSERTпроизводителност:клъстерният индекс печели с около 3% поради второто записване, необходимо за купчина.UPDATEпроизводителност:клъстерният индекс печели с около 8% поради второто търсене, необходимо за купчина.DELETEпроизводителност:клъстерният индекс печели с около 18% поради необходимостта от второ търсене и второто изтриване, необходимо от IAM за куп.- единичен
SELECTпроизводителност:клъстерният индекс печели с около 16% поради второто търсене, необходимо за купчина. - обхват
SELECTпроизводителност:клъстерираният индекс печели с около 29% поради произволното подреждане за куп. - едновременно
INSERT:heap таблицата печели с 30% при натоварване поради разделяне на страници за клъстерирания индекс.
