Návrh a optimalizace databáze

Většině pomalých databází chybí zřejmý index

Když aplikace s růstem zpomaluje, příčinou obvykle není server ani databázový engine. Je to hrstka dotazů, které procházejí celé tabulky, protože žádný index neodpovídá způsobu jejich hledání. Dotaz, který trval 20 milisekund u 1 000 řádků, může u milionu trvat sekundy, a nikdo si toho nevšimne, dokud si toho nevšimnou zákazníci.

Začínáme od důkazů: vlastní statistiky databáze o tom, které dotazy běží nejčastěji a trvají nejdéle. To obvykle ukáže na krátký seznam oprav, jako je index na sloupce používané častým filtrem, přepsaný dotaz, který nenačítá celé tabulky, nebo chybějící propojení mezi tabulkami, které nutí k opakovanému vyhledávání. Každý dotaz měříme před a po, takže zlepšení je vidět, a ne jen tvrzené.

Omezení zastaví špatná data už u vchodu

Mnoho databází spoléhá na to, že data udrží v pořádku aplikace. Aplikace kontroluje, že e-mail je jedinečný, že objednávka patří skutečnému zákazníkovi, že množství není záporné. Pak ale druhá aplikace, importní skript nebo uspěchaná ruční oprava tyto kontroly přeskočí a začnou se množit duplicity a osiřelé záznamy. Reporty si začnou odporovat a nikdo si není jistý, které číslo je správné.

Dobře navržené schéma vynucuje důležitá pravidla samo: jedinečné omezení, cizí klíče, kontrolní omezení a rozumné výchozí hodnoty. Cokoli, co do databáze zapisuje, je musí dodržet. U existujícího systému najdeme, kde už se data rozcházejí, naplánujeme jejich vyčištění a pak přidáme omezení, aby se to už neopakovalo.

• Jedinečná omezení u toho, co se nesmí opakovat, například e-maily nebo čísla faktur
• Cizí klíče, aby záznamy nemohly odkazovat na něco, co neexistuje
• Kontrolní omezení pro hodnoty, které musí zůstat v rozmezí
• Indexy vybrané podle skutečných vzorců dotazů, ne přidané všude