Przyczyny, dla których nie ma indeksu klastrowanego w SQL Server 2005

Question

Odziedziczyłem niektóre skrypty do tworzenia baz danych dla bazy danych SQL SERVER 2005.

Jedną z rzeczy, które zauważyłem jest to, że wszystkie klucze podstawowe są tworzone jako indeksy NON CLUSTERED w przeciwieństwie do klastrów.

Wiem, że możesz mieć tylko jeden indeks klastrowany na tabelę i że możesz chcieć mieć go na kolumnie klucza niebędącego kluczem podstawowym dla wyników wyszukiwania zapytań itp. Jednak nie ma innych indeksów CLUSTERED na tabelach w pytaniach.

Moje pytanie brzmi, czy istnieją techniczne powody, dla których nie należy tworzyć indeksów klastrowych w kolumnie klucza głównego, z wyjątkiem powyższych.

Answer 1

Na każdej "normalnej" tabeli danych lub wyszukiwania: nie, nie widzę żadnego powodu.

Na takie rzeczy jak tabele importu zbiorczego lub tabele tymczasowe - to zależy.

Dla niektórych osób zaskakujące wydaje się, że posiadanie indeksu klastrowego właściwie może przyspieszyć operacje takie jak INSERT lub UPDATE. Zobacz blog na blogu Kimberly Tripps: The Clustered Index Debate continues...., w którym wyjaśnia szczegółowo, dlaczego tak się dzieje.

W tym świetle: Nie widzę żadnegoważny powód nie mieć dobrą indeksu klastrowego (wąski, stabilny, niepowtarzalny, coraz większa = INT IDENTITY jako najbardziej oczywistym wyborem) na dowolnej tabeli SQL Server .

Aby uzyskać pewne głębokie wgląd w jaki sposób i dlaczego wybrać klucze klastrów, czytać wszystko znakomitych blogach Kimberly Tripp na ten temat:

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

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

Doskonałe rzeczy z „Królowej indeksowania "!:-)

Answer 2

Clustered Tables vs Heap Tables

(dobry artykuł na temat w www.mssqltips.com)

HEAP tabeli (bez klastra index)

• dane nie są przechowywane w określonej kolejności

• Dane szczegółowe c a nie być pobierane szybko, chyba że istnieją również nieklastrowanym indeksy

• strony dane te nie są ze sobą powiązane, tak sekwencyjny dostęp musi odesłać na mapie alokacji indeksu (IAM) stron

• Ponieważ nie ma indeksu klastrowego, dodatkowy czas nie jest potrzebna do utrzymać indeks

• Ponieważ nie ma indeksu klastrowego, nie jest th e potrzeba dodatkowego przestrzeni do przechowywania indeksu klastrowego drzewo

• Tabele te mają index_id wartość 0 w widoku katalogu sys.indexes

Klastry Tabela

• Dane są przechowywane w kolejności według klucza klastrowanego

• Dane mogą być pobierane szybko oparty na klastrowym klucza indeksu, jeśli zapytanie wykorzystuje indeksowanych kolumn

• stron danych są połączone w celu szybszego dostępu sekwencyjnego potrzebne jest dodatkowy czas, aby utrzymać indeks klastra na podstawie wkładki, aktualizacje i usuwa

• potrzebna jest dodatkowa przestrzeń do przechowywania klastrowych drzewo indeksu tych tabelach mają index_id wartość 1 w katalogu sys.indexes view

Answer 3

Tutaj jest inny (czy już zostały dostarczone w innych odpowiedziach?) Możliwych przyczyn (wciąż należy rozumieć):

• SQL Server - Poor performance of PK delete

mam nadzieję, będę aktualizować później, ale na razie jest to raczej chęć powiązania tych tematów

Aktualizacja:
What do I miss in understanding the clustered index?

Answer 4

Proszę przeczytać moją odpowiedź pod "Brak bezpośredniego dostępu do wiersza danych w tabeli w klastrze - dlaczego?", pierwszy. W szczególności item [2] Caveat.

Ludzie, którzy stworzyli "bazę danych", są kretynami. Mieli:

• grono zdenormalizować spreadhseets nie znormalizowane tabele relacyjne
• PKS są wszystkie kolumny tożsamości (te arkusze są połączone ze sobą, muszą być one poruszać się jeden po jedno- jeden-jeden); nie ma relacyjny dostępu lub relacyjnych moc całej bazy
• mieli PRIMARY KEY, które produkują UNIQUE klastrowych
• odkryli, że zapobiega współbieżność
• one usunięte CI i uczynił je wszystkie NCIS
• Byli zbyt leniwy, aby zakończyć odwrócenie; mianować zastępcę (prąd NCI), aby stać się nową CI dla każdej tabeli
• kolumna tożsamość pozostaje klucz podstawowy (to naprawdę nie jest, ale jest w tym hamfisted realizacji)

W przypadku takich kolekcji arkuszy kalkulacyjnych, które podszywają się pod bazy danych, coraz powszechniejsze staje się unikanie CI, a jedynie posiadanie NCI i sterty. Oczywiście nie mają żadnej mocy ani korzyści CI, ale, do diabła, nie mają żadnej mocy ani korzyści Relacyjnych baz danych, więc kogo to obchodzi, że nie mają żadnej mocy CI (które zostały zaprojektowane dla Relacyjnych baz danych, które ich nie jest). Sposób, w jaki na to patrzą, muszą co jakiś czas "odnawiać" cętki, więc po co zawracać sobie głowę. Relacyjne bazy danych nie wymagają "refaktoryzacji".

Jeśli chcesz dalej omawiać tę odpowiedź, opublikuj tabelę CREATE TABLE/INDEX DDL; inaczej jest marnującym czas akademickim argumentem.

Answer 5

Niektóre serwery b-tree/języki programowania nadal używane dzisiaj do przechowywania danych używają plików płaskich ascii o stałej lub zmiennej długości. Kiedy nowy plik danych/wiersz zostanie dodany do pliku (tabela), rekord jest (1) dołączany na końcu pliku (lub zastępuje usunięty rekord) i (2) indeksy są zrównoważone. Kiedy dane są przechowywane w ten sposób, nie musisz martwić się o wydajność systemu (o ile robi to serwer b-tree, aby zwrócić wskaźnik do pierwszego rekordu danych). Czas odpowiedzi jest osiągany tylko przez liczbę węzłów w plikach indeksowych.

Kiedy zaczynasz używać SQL, masz nadzieję, że zdasz sobie sprawę, że wydajność systemu musi być brana pod uwagę przy każdym napisaniu instrukcji SQL. Użycie instrukcji "ORDER BY" na nieindeksowanej kolumnie może doprowadzić system do kolan. Używanie indeksu klastrowego może spowodować niepotrzebne obciążenie procesora. Jest to wiek XXI i żałuję, że nie musieliśmy myśleć o wydajności systemu podczas programowania w SQL, ale wciąż to robimy.

W przypadku niektórych starszych języków programowania obowiązkowe było korzystanie z indeksu po otrzymaniu posortowanych danych. Żałuję tylko, że ten wymóg nie został jeszcze przyjęty. Mogę się tylko zastanowić, ile firm zaktualizowało swoje powolne systemy komputerowe ze względu na źle napisaną instrukcję SQL dotyczącą nieindeksowanych danych.

W ciągu 25 lat programowania nigdy nie potrzebowałem danych fizycznych przechowywanych w określonej kolejności, więc może dlatego niektórzy programiści unikają stosowania indeksów klastrowych. Trudno się zorientować, co to jest kompromis (czas przechowywania, czas wczytywania wierszy), szczególnie jeśli projektowany system może przechowywać miliony rekordów pewnego dnia.