it-swarm-eu.dev

Jak zjistit, zda je Index vyžadován nebo nezbytný

V naší databázi MS SQL jsem spustil nástroj pro automatické indexování (upravil jsem skript pocházející od společnosti Microsoft, který se dívá na tabulky statistických indexů - Automatické automatické indexování ). Ze statistik nyní mám seznam doporučení pro indexy, které je třeba vytvořit.

Edit: Výše ​​popsané indexy přebírají informace od DMV, které vám řeknou, co by databázový stroj použil pro indexy, pokud by byly dostupné, a skripty přijímají doporučení Top x (podle vyhledávání, dopadu na uživatele atd.) a vkládají je do tabulky.

(Úpravy výše částečně převzaté z odpovědi Larryho Colemana níže s cílem objasnit, co skripty dělají)

Vzhledem k tomu, že jsem novým administrátorem databáze, a poté, co jsem rychle prohledal síť, se zdráhám vrhnout se a slepě přidat doporučené indexy. Vzhledem k tomu, že v této oblasti nemáme zkušenosti, hledám radu, jak zjistit, zda jsou doporučení nezbytná nebo ne.

Musím spustit SQL Profiler, nebo je lepší prozkoumat kód, který dotazuje tabulky? A máte nějaké další rady?

112
misterjaytee

Používám skripty indexové analýzy Jason Strate (staré umístění) . Řeknou vám, kolik vašich existujících indexů je použito a kolik chybějících indexů by bylo použito. Obvykle nepřidávám indexy, pokud netvoří více než 5 nebo 10% dotazů v tabulce.

Nejdůležitější však je, že se jedná o to, aby aplikace reagovala dostatečně rychle na uživatele.

Aktualizace: Články blogu o analýze indexů Jason Strate pro novější skripty (Nové umístění)

Double Update: V těchto dnech používám při provádění indexové analýzy sp_BlitzIndex® .

81

Existuje několik konceptů a termínů, které je důležité pochopit při práci s indexy. Vyhledávání, skenování a vyhledávání jsou některé ze způsobů, jak budou indexy využívány prostřednictvím vybraných příkazů. Selektivita sloupců klíčů je nedílnou součástí určení toho, jak efektivní může být index.

Hledání se stane, když Optimalizátor dotazů serveru SQL určí, že nejlepším způsobem, jak najít požadovaná data, je skenování rozsahu v indexu. Hledá se obvykle, když je dotaz „pokrytý“ indexem, což znamená, že predikáty hledání jsou v klíči indexu a zobrazené sloupce jsou buď v klíči, nebo jsou zahrnuty. Ke skenování dochází, když Optimalizátor dotazů serveru SQL určí, že nejlepším způsobem, jak najít data, je skenovat celý index a pak filtrovat výsledky. K vyhledávání obvykle dochází, když index neobsahuje všechny požadované sloupce, buď v klíči indexu, ani v zahrnutých sloupcích. Optimalizátor dotazů potom použije k vyhledání dalších požadovaných sloupců buď seskupený klíč (proti seskupenému indexu), nebo RID (proti haldě).

Operace vyhledávání jsou obvykle efektivnější než skenování díky fyzickému dotazování menší sady dat. Existují situace, kdy tomu tak není, například velmi malý počáteční soubor údajů, ale to přesahuje rámec vaší otázky.

Nyní jste se zeptali, jak zjistit, jak efektivní je index, a existuje několik věcí, které byste měli mít na paměti. Sloupce klíče seskupeného indexu se nazývají klastrovací klíč. Takto jsou záznamy vytvořeny jedinečně v kontextu seskupeného indexu. Všechny neclusterované indexy budou ve výchozím nastavení zahrnovat seskupený klíč, aby bylo možné v případě potřeby provést vyhledávání. Všechny indexy budou vloženy, aktualizovány nebo odstraněny z každého příslušného příkazu DML. Jak již bylo řečeno, je nejlepší vyvažovat přírůstky výkonu ve vybraných příkazech s požadavky na výkon v příkazech vložení, odstranění a aktualizace.

Chcete-li zjistit, jak efektivní je index, musíte určit selektivitu indexových klíčů. Selektivita může být definována jako procento různých záznamů z celkových záznamů. Pokud mám tabulku [person] s celkem 100 záznamy a sloupec [first_name] obsahuje 90 různých hodnot, můžeme říci, že sloupec [first_name] je 90% selektivní. Čím je vyšší selektivita, tím účinnější je indexový klíč. S ohledem na selektivitu je nejlepší vložit do indexového klíče vaše nejelektivnější sloupce. Co kdybych použil můj předchozí příklad [person], co kdybychom měli sloupec [last_name], který byl 95% selektivní? Chtěli bychom vytvořit index s [last_name], [first_name] jako indexovým klíčem.

Vím, že to byla poněkud dlouhotrvající odpověď, ale ve skutečnosti existuje spousta věcí, které určují, jak efektivní bude index, a spousta věcí, které musíte zvážit, se zvýšením výkonu proti.

51
Matt M

Nedávno jsem objevil fantastický bezplatný skript od lidí na BrentOzar Unltd http://www.brentozar.com/blitzindex/

Tím se provede dobrá analýza toho, které indexy existují, jak často se používají a jak často vyhledávací modul hledá index, který neexistuje.

Jeho vedení je obecně dobré. Někdy je to trochu přehnaně nápadité. Dosud jsem obecně udělal následující:

  • Odstraněné indexy, které NIKDY nebyly přečteny (nebo možná méně než 50krát za měsíc).
  • Přidány nejviditelnější indexy cizích klíčů a polí, o kterých vím, že jich používáme hodně.

Nepřidal jsem všechny doporučené indexy a vrátil jsem se o týden později, abych zjistil, že již nejsou doporučovány, protože dotazovací modul místo toho používá některé z dalších nových indexů!

Obecně byste se měli vyhnout indexům:

  • Velmi malé tabulky (méně než 50 až 200 záznamů): často je dotazovací modul rychlejší, pokud prohledává tabulku namísto načítání indexu, čtení, zpracování atd.
  • Vyhněte se indexům ve sloupcích s nízkou kardinálností ( http://en.wikipedia.org/wiki/Cardinality_ (SQL_statements) ) v prvním uvedeném sloupci. Např. Indexování genderového pole (M/F) je velmi málo užitečné, je stejně praktické prohledat tabulku a najít ~ 50%, které odpovídají. Pokud je v rejstříku uvedeno něco konkrétnějšího (např. [Datum narození, pohlaví]), je to lepší - možná byste chtěli, aby se všichni muži narodili v daném časovém období.

Klastrované indexy jsou dobré - obvykle jsou založeny na primárním klíči. Pomáhají databázovému stroji dát data na disk v dobrém stavu. Je velmi důležité porozumět tomu u největších tabulek, protože dobrý seskupený index často snižuje místo, které tabulka zabírá.

Některé tabulky jsem snížil z 900 MB na 400 MB, jen proto, že to byly předem nevybudované hromady. http://msdn.Microsoft.com/en-us/library/aa933131 (v = sql.80) .aspx

Reorganizovat/znovu vytvořit

Měli byste hledat kontrolu fragmentovaných indexů. Trocha roztříštěnosti je v pořádku, nebuď posedlá! http://technet.Microsoft.com/en-us/library/ms189858.aspx Znáte rozdíl mezi reorganizací a obnovením!

Pravidelně kontrolujte

Změny dotazů, změna objemu dat, přidání nových funkcí, odstranění starých. Měli byste se na ně dívat jednou za měsíc (nebo častěji, pokud máte velké objemy) a hledat, kde můžete databázi pomoci!

Kolik

V nedávném videu Brent doporučuje (obvykle) ne více než 5 indexů na tabulce se spoustou zápisu (např. Tabulka objednávek), a ne více než 10, pokud je přečteno mnohem více než zapsáno (tj. Logovací tabulka pro analýzu) http://www.youtube.com/watch?v=gOsflkQkHjg

Celkově

Záleží!

Váš počet najetých kilometrů se liší podle databáze. Zřetelné (příjmení zaměstnance, datum objednávky atd.) Zakryjte na (nyní/budoucích) větších tabulkách. Sledujte, kontrolujte a upravujte podle potřeby. Mělo by být součástí běžného kontrolního seznamu při správě databáze (databází) :)

Snad to pomůže!

29
Greg Robson

Obvykle jde o konkrétní pracovní vytížení (dotazy) a pečlivé testování dopadu každého nového indexu na pracovní vytížení. Tento iterační proces by měl vždy zahrnovat pečlivou analýzu prováděcích plánů, která odhalí, jaké indexy se používají. Téma analýzy dotazu je zdlouhavé a počínaje vyhrazenou kapitolou MSDN Analýza dotaz je dobrá sázka.

Někdy, když je pracovní vytížení příliš složité nebo pokud je znalost návrhu databáze povrchní, použije se Poradce pro optimalizaci databázového stroje , který provede nějakou automatickou analýzu vašeho pracovního vytížení a navrhuje některé indexy. Návrhy by samozřejmě měly být pečlivě analyzovány a dopad by měl být okamžitě změřen.

Pokud tedy budete postupovat podle mého nápadu, přidání indexu a měření dopadu je opravdu jen případ testování A/B : pracovní zátěž bez indexu spustíte jako základní linii, pak ji spustíte s indexem, změřte a porovnejte se základní linií a poté na základě pozorovaných a měřených metrik rozhodněte, zda je dopad příznivý. Pracovní vytížení je nejlepší testovací souprava dobré kvality, ale může to být také přehrání zachyceného pracovního vytížení, viz Jak: Přehrát stopový soubor .

Syntetičtější odpověď je podívat se na sys.dm_db_index_usage_stats zobrazit a vidět, jak jsou indexy využívány, ale to je obvykle přístup k provádění analýzy na místě na neznámém pracovním vytížení (tj. s tím by pravděpodobně začínal konzultant zavolaný na pomoc).

14
Remus Rusanu

Počínaje SQL 2005, SQL Server má DMV , které vám říkají, co by databázový stroj použil pro indexy, pokud by byly k dispozici. Pohledy vám řeknou, které sloupce by měly být klíčové sloupce, které sloupce by měly být zahrnuty, a co je nejdůležitější, kolikrát by byl index použit.

Dobrým přístupem by bylo třídění chybějících indexů dotazu podle počtu pokusů a nejprve zvážit přidání nejvyšších indexů.

Viz také: oficiální dokumenty MS DMV

8
Larry Coleman