sql >> Databáze >  >> RDS >> Database

Zmírnění fragmentace indexu


To také není dobrá fragmentace

Minulý měsíc jsem psal o neočekávané fragmentaci seskupeného indexu, takže tentokrát bych rád probral některé věci, které můžete udělat, abyste fragmentaci indexu zabránili. Předpokládám, že jste si přečetli předchozí příspěvek a jste obeznámeni s pojmy, které jsem tam definoval, a ve zbytku tohoto článku, když říkám „fragmentace“, mám na mysli problémy logické fragmentace a nízké hustoty stránek.

Vyberte dobrý clusterový klíč

Nejdražší datovou strukturou, se kterou lze operovat za účelem odstranění fragmentace, je seskupený index tabulky, protože je to největší struktura, protože obsahuje všechna data tabulky. Z hlediska fragmentace má smysl zvolit klastrový klíč, který odpovídá vzoru vložení tabulky, takže není možné, aby se vložení stalo na stránce, kde není místo, a tím způsobilo rozdělení stránky a zavedení fragmentace.

Co představuje nejlepší klíč clusteru pro danou tabulku, je předmětem mnoha debat, ale obecně neuděláte chybu, pokud má váš klíč clusteru následující jednoduché vlastnosti:

  • Úzké (tj. co nejméně sloupců)
  • Statické (tj. nikdy jej neaktualizujete)
  • Unikátní
  • Stále rostoucí

Je to stále se zvyšující vlastnost, která je nejdůležitější pro prevenci fragmentace, protože se vyhýbá náhodným vkládáním, které mohou způsobit rozdělení stránek na již plných stránkách. Příkladem takové volby klíče jsou sloupce identity int a bigint identity nebo dokonce sekvenční GUID z funkce NEWSEQUENTIALID().

S těmito typy klíčů budou mít nové řádky hodnotu klíče zaručeně vyšší než všechny ostatní v tabulce, takže kurzor nového řádku bude na konci stránky úplně vpravo ve struktuře seskupeného indexu. Nové řádky nakonec tuto stránku zaplní a na pravou stranu indexu bude přidána další stránka, ale nedojde k žádnému škodlivému rozdělení stránky.

Nyní, pokud máte seskupený indexový klíč, který se stále nezvyšuje, může být velmi složitý a nepříjemný postup změnit jej na stále se zvyšující, takže se nebojte – místo toho můžete použít faktor plnění, jak jsem probíral níže.

Mimochodem, pro mnohem hlubší vhled do výběru klastrového klíče a všech jeho důsledků se podívejte na kategorii blogu Kimberly's Clustering Key (čtěte zdola nahoru).

Neaktualizovat klíčové sloupce indexu

Kdykoli se aktualizuje klíčový sloupec, nejedná se pouze o jednoduchou aktualizaci na místě, i když na mnoha místech online a v knihách to tak je (mýlí se). Sloupec klíče nelze aktualizovat na místě, protože nová hodnota klíče by pak znamenala, že řádek je pro index v nesprávném pořadí klíčů. Místo toho je aktualizace klíčového sloupce převedena na odstranění celého řádku plus vložení celého řádku s novou hodnotou klíče. Pokud na stránce, kam bude vložen nový řádek, není dostatek místa, dojde k rozdělení stránky, což způsobí fragmentaci.

Vyhnout se aktualizacím sloupce klíče by mělo být pro seskupený index snadné, protože je to špatný návrh, který vyžaduje aktualizaci klíče clusteru řádku tabulky. U indexů bez klastrů je však nevyhnutelné, pokud aktualizace tabulky náhodou zahrnují sloupce, na kterých je index bez klastrů. V těchto případech budete muset použít faktor plnění.

Neaktualizovat sloupce s proměnnou délkou

Tohle se snadněji řekne, než udělá. Pokud musíte použít sloupce s proměnnou délkou a je možné, že budou aktualizovány, je možné, že se mohou zvětšit, a tak vyžadovat více místa pro aktualizovaný řádek, což vede k rozdělení stránky, pokud je stránka již plná.

Existuje několik věcí, které můžete udělat, abyste se v tomto případě vyhnuli fragmentaci:

  • Použijte faktor plnění
  • Pokud je režie všech nadbytečných výplňových bajtů menší problém než fragmentace nebo použití faktoru vyplnění, použijte místo toho sloupec s pevnou délkou.
  • Použijte zástupnou hodnotu k „rezervaci“ místa pro sloupec – toto je trik, který můžete použít, pokud aplikace zadá nový řádek a poté se vrátí a vyplní některé podrobnosti, což způsobí rozšíření sloupců s proměnnou délkou
  • li>
  • Namísto aktualizace proveďte odstranění a vložení

Použijte faktor plnění

Jak vidíte, mnoho způsobů, jak se vyhnout fragmentaci, je nechutných, protože zahrnují změny aplikace nebo schématu, a proto je použití faktoru plnění snadným způsobem, jak fragmentaci zmírnit.

Faktor naplnění indexu je nastavení pro index, které určuje, kolik prázdného místa ponechat na každé stránce na úrovni listu, když je index vytvořen, přestavěn nebo reorganizován. Myšlenka je taková, že na stránce je dostatek volného místa, aby bylo možné náhodně vkládat nebo zvětšovat řádky (z přidávané značky pro správu verzí nebo aktualizovaných sloupců s proměnnou délkou), aniž by se stránka zaplňovala a vyžadovalo rozdělení stránky. Stránka se však nakonec zaplní, a tak je třeba pravidelně obnovovat volné místo přestavbou nebo reorganizací indexu (obecně se nazývá provádění údržby indexu). Trik je v nalezení správného faktoru plnění, který se má použít, spolu se správnou periodicitou údržby indexu.

Více o nastavení faktoru plnění v MSDN si můžete přečíst zde. Nespadněte do pasti nastavení faktoru vyplnění pro celou instanci (pomocí sp_configure), protože to znamená, že všechny indexy budou znovu sestaveny nebo reorganizovány pomocí této hodnoty faktoru vyplnění, dokonce i ty indexy, které nemají žádné problémy s fragmentací. Nechcete, aby vaše velké seskupené indexy s pěknými stále se zvětšujícími klíči promarnily 30 % místa na úrovni listu při přípravě na náhodné vkládání, ke kterému nikdy nedojde. Je mnohem lepší zjistit, které indexy jsou skutečně ovlivněny fragmentací, a pouze u nich nastavit faktor plnění.

Na to vám nemůžu dát žádnou správnou odpověď ani kouzelný vzorec. Obecně přijímanou praxí je zavést faktor plnění 70 (to znamená ponechat 30 % volného místa) pro ty indexy, kde je fragmentace problémem, sledovat, jak rychle dochází k fragmentaci, a poté upravit buď faktor plnění, nebo frekvenci údržby indexu. (nebo obojí).

Ano, to znamená, že záměrně plýtváte místem v indexech, abyste se vyhnuli fragmentaci, ale je to dobrý kompromis vzhledem k tomu, jak drahé je rozdělení stránek a jak může být fragmentace škodlivá pro výkon. A ano, navzdory tomu, co by někteří mohli říkat, je to stále důležité, i když používáte SSD.

Shrnutí

Existuje několik jednoduchých věcí, které můžete udělat, abyste se fragmentaci vyhnuli, ale jakmile se dostanete do neshlukovaných indexů nebo použijete izolaci snímků nebo čitelné sekundární položky, fragmentace postaví svou ošklivou hlavu a musíte se jí pokusit zabránit.

Nyní neškubejte a nemyslete si, že byste měli nastavit faktor plnění 70 na všech svých instancích – musíte je vybrat a nastavit pečlivě, jak jsem popsal výše.

A nezapomeňte na SQL Sentry Fragmentation Manager, který vám (jako doplněk k Performance Advisor) pomůže zjistit, kde jsou problémy s fragmentací, a následně je řešit. Například na kartě Indexy můžete snadno seřadit své indexy nejprve podle nejvyšší fragmentace (a pokud chcete, použít filtr na sloupec počtu řádků, abyste ignorovali menší tabulky):

A pak zjistěte, zda tyto indexy používají výchozí faktor plnění (0 %), nebo možná jiný než výchozí faktor plnění, který nemusí být vhodný pro vaše data a vzory DML. Nechám vás hádat, které z nich na výše uvedeném snímku obrazovky bych měl největší zájem prozkoumat. Implementace vhodnějších faktorů plnění indexu je nejjednodušší způsob, jak vyřešit jakékoli problémy, které si všimnete.


  1. MariaDB CURRENT_DATE() Vysvětleno

  2. Při vkládání dat do oracle není platný měsíc

  3. Oracle:načítání velkého souboru xml?

  4. Jakou verzi PostgreSQL používám?