Když přidání indexu věci zpomalí

Tabulka denních hodnot má jeden klíč: počítadlo a datum dohromady. Pět míst v kódu se jí ale ptá jinak — ne „toto počítadlo v čase“, nýbrž „všechna počítadla v těchto dnech“. Galerie na hlavní stránce, žebříček, sitemap, graf za 90 dní a stavové údaje. Bez indexu na sloupci s datem čte každý z těchto dotazů všech 114 113 řádků.

Přidání tohoto indexu zrychlí galerii desetkrát. Přidán nebyl. Tady je měření, které o tom rozhodlo.

Jeden dotaz se výrazně zrychlil

Galerie se ptá na počítadla, která byla dnes aktivní. Bez indexu na datu prochází celou tabulku; s ním vyhledá jediné datum a přečte 443 řádků. Z 61,5 milisekundy se stalo 6,1. To není nenápadný výsledek, a kdyby se měřilo jen tohle, index by už v databázi byl.

Dva dotazy se zpomalily

Sitemap se ptá na čtrnáct dní a zpomalila se o 19 %. Stavové údaje se ptají na rok a zpomalily se o 10 %. V obou případech plánovač dotazů přešel z primárního klíče na nový index a vybral hůř.

Tohle je ta část, kterou stojí za to pochopit, protože nejde o chybu plánovače. Čtení rozsahu přes sekundární index znamená najít odpovídající řádky v indexu a pak každý z nich načíst z tabulky. U úzkého výřezu je to výhodné. U čtrnácti dní ze třinácti měsíců je to pořád spousta řádků načítaných jeden po druhém, a prosté projití tabulky — čtení ve fyzickém pořadí, které disky a mezipaměti mají rády — vyjde lépe. Plánovač to neví. Vidí rozsah a index a sáhne po něm.

Nedá se říct „použij tento index jen pro galerii“. Index je k dispozici každému dotazu, který se daného sloupce dotýká, a plánovač ho použije všude, kde mu to jeho odhady radí. Přidat ho znamená změnit každý dotaz nad touto tabulkou, ne jen ten, pro který byl zamýšlen.

Dohromady: nic

Přes všech pět dotazů se z 555 milisekund stalo 524. Zlepšení 1,1×, které na malém serveru, jenž tyto stránky stejně obsluhuje z mezipaměti, nestojí za změnu schématu.

Graf za 90 dní vypadá, že se zlepšil o 9 %. Nezapočítává se a stojí za to říct proč. Každý dotaz byl změřen třikrát: bez indexu, s ním a pak znovu bez něj. Pokud druhý běh bez indexu nevyjde blízko prvnímu, rozdíl způsobil stroj, ne změna. U grafu za 90 dní se oba běhy bez indexu lišily o 13,8 % — víc, než je tvrzený účinek. Ten řádek tedy neměří nic a jako nic je také uveden.

Jak se měřilo a proč na tom záleží

Ne na živé tabulce. Skript ji zkopíruje, pracuje s kopií a na konci kopii smaže. Přidat index do produkční tabulky, jen abyste viděli, co se stane, funguje jen jednou na každé překvapení.

Dotazy jsou ty skutečné, vzaté z kódu, včetně spojení s tabulkou počítadel. Dřívější verze tohoto testu použila zjednodušenou náhradu a dala mnohem vzrušující odpověď: dvacetkrát rychleji. Ten zjednodušený dotaz ale ve skutečnosti nic nespouští.

Jaké číslo by vyšlo

Kdyby se to měřilo obvyklým způsobem — vzít dotaz, který se zdá pomalý, a změřit ho před změnou a po ní — odpověď by zněla „desetkrát rychleji, nasadit“. Index by přibyl, galerie by se zrychlila, sitemap a stavová stránka by se zpomalily a nikdo by to nespojil, protože je nikdo nesledoval.

Tak to obecně vypadá. Změnu sdílené infrastruktury nelze posoudit na případu, který ji vyvolal. Otázka nezní „pomůže to tomu, na co se dívám“, ale „co dalšího na to sahá a co se s tím stane“.

Existuje varianta, která by fungovat mohla: index nesoucí oba sloupce, datum jako první, aby galerie dostala odpověď jen z indexu bez návratu do tabulky. Možná by také nesváděl plánovač u širších rozsahů. To změřeno nebylo, takže to není doporučení — je to další věc, kterou vyzkoušet na kopii.