sql >> Databáze >  >> RDS >> Sqlserver

Měla by mít každá tabulka uživatelů seskupený index?

Je těžké to vyjádřit stručněji než MVP SQL Server Brad McGehee:

Všeobecně platí, že každá tabulka by měla mít seskupený index. Obecně, ale ne vždy, by měl být seskupený index ve sloupci, který se monotónně zvyšuje – jako je sloupec identity nebo jiný sloupec, kde se hodnota zvyšuje – a je jedinečný. V mnoha případech je primární klíč ideálním sloupcem pro seskupený index.

BOL odráží tento sentiment:

Až na několik výjimek by každá tabulka měla mít seskupený index.

Důvodů, proč tak činí, je mnoho a jsou založeny především na skutečnosti, že sdružený index fyzicky objednává vaše data v úložišti .

  • Pokud je váš seskupený index na jednom sloupci, monotónně se zvyšuje, vloží se na vašem úložném zařízení v pořadí a k rozdělení stránek nedojde.

  • Seskupené indexy jsou účinné pro nalezení konkrétního řádku, když je indexovaná hodnota jedinečná, jako je běžný vzor výběru řádku na základě primárního klíče.

  • Seskupený index často umožňuje efektivní dotazy na sloupce, které se často hledají pro rozsahy hodnot (between , > , atd.).

  • Clustering může urychlit dotazy, kde jsou data běžně řazena podle určitého sloupce nebo sloupců.

  • Klastrovaný index lze na požádání znovu sestavit nebo reorganizovat, aby bylo možné řídit fragmentaci tabulky.

  • Tyto výhody lze dokonce aplikovat na zobrazení.

Možná nebudete chtít mít seskupený index na:

  • Sloupce, ve kterých dochází k častým změnám dat, protože SQL Server musí data v úložišti fyzicky znovu uspořádat.

  • Sloupce, které jsou již pokryty jinými indexy.

  • Široké klíče, protože seskupený index se také používá při vyhledávání indexů bez klastrů.

  • Sloupce GUID, které jsou větší než identity a také účinně náhodné hodnoty (pravděpodobně nebudou seřazeny podle), ačkoli newsequentialid() lze použít ke zmírnění fyzického přeskupování během vkládání.

  • Vzácným důvodem pro použití haldy (tabulky bez seskupeného indexu) je situace, kdy je k datům vždy přistupováno prostřednictvím neklastrovaných indexů a je známo, že RID (interní identifikátor řádku SQL Serveru) je menší než seskupený indexový klíč.

Kvůli těmto a dalším úvahám, jako je například pracovní vytížení vaší konkrétní aplikace, byste měli pečlivě vybírat své seskupené indexy, abyste získali maximální užitek pro vaše dotazy.

Všimněte si také, že když vytvoříte primární klíč v tabulce na serveru SQL Server, ve výchozím nastavení se vytvoří jedinečný seskupený index (pokud již žádný nemá). To znamená, že pokud najdete tabulku, která nemá seskupený index, ale má primární klíč (jako by měly všechny tabulky), vývojář se již dříve rozhodl vytvořit ji tímto způsobem. Možná budete chtít mít pádný důvod to změnit (kterých je mnoho, jak jsme viděli). Přidání, změna nebo zrušení seskupeného indexu vyžaduje přepsání celé tabulky a jakékoli indexy bez klastrů, takže to může na velké tabulce nějakou dobu trvat.



  1. ORA-00257:Chyba archivátoru. Připojte pouze interní, dokud se neuvolní.

  2. Práce kolem zmeškaných optimalizací

  3. chyba:ORA-65096:neplatný společný název uživatele nebo role v oracle

  4. Porovnání Oracle MySQL, Percona Server a MariaDB