Chcete-li maximální rychlost vyhledávání a mít oba sloupce v podmínkách spojení nebo kde, ALE někdy má sloupec a vyšší selektivitu a někdy sloupec b vyšší selektivitu a chcete tuto skutečnost využít z jediného indexu.
Také si myslím, že váš poměr velikost dat / výkon stroje by měl být poměrně vysoký a zároveň budete muset (odhadnout) být ochotni označit jakékoli zlepšení za nutnost (byť jen o pár procent).
Přesto zkušenost učí, že věci závisí na mnoha faktorech; se specifickými RDBMS a aplikačními prostředími je lepší spouštět vlastní benchmarky.
EDIT:Další vysvětlení ke složeným indexům.z wikipedie
:
"Pořadí, ve kterém jsou sloupce uvedeny v definici indexu, je důležité. Je možné získat sadu identifikátorů řádků pouze pomocí prvního indexovaného sloupce. Není to však možné ani efektivní (na většina databází) k načtení sady identifikátorů řádků pouze pomocí druhého nebo většího indexovaného sloupce.
Představte si například telefonní seznam, který je uspořádán nejprve podle města, poté podle příjmení a poté podle jména. jsou uvedeny ve městě, můžete snadno získat seznam všech telefonních čísel pro toto město. V tomto telefonním seznamu by však bylo velmi zdlouhavé najít všechna telefonní čísla pro dané příjmení. Museli byste hledat v rámci každého města sekce pro záznamy s tímto příjmením."
Vysvětlení Wikipedie je možná příliš zjednodušené, ale poskytuje vám základní myšlenku (jak jdou analogie, mějte na paměti, že telefonní seznamy mají obvykle seskupené indexy a to by nebyl váš obecný databázový index).
V závislosti na velikosti indexu vs. velikost datové struktury vs. dostupná paměť vs. selektivita v prvním sloupci indexu může být stále mnohem levnější použít nesprávně uspořádaný index než použít skenování tabulek.
Aha, jen mě napadla lepší analogie s příkladem, který hledáte Představte si pěknou učebnici, měla by obsah s kapitolami a podkapitolami a počet stránek, na kterých se nacházejí (což je neshlukovaný index, který drží ukazatele na datové záznamy - stránky). Nyní si představte, že učebnice je na standardu SQL-92, pak by většina výrazů v TOC byla výrazy SQL (dodržujte tento předpoklad). Také byste měli na konci knihy další rejstřík, který by uveďte všechny zajímavé výrazy v abecedním pořadí (předpokládejme s názvy hlavních kapitol) a čísly stránek.
Pro otázku typu 'Řekni mi všechny kapitoly, pod kterými se DISTINCT objevují' byste použili druhý index. (protože selektivita pozdějšího pole je vysoká)
Pro otázku typu „Řekni mi počet výrazů, které se objevují v první kapitole“ byste použili TOC
Takže pro otázky typu 'Je SELECT popsán v kapitole DML?' můžete použít kterýkoli z indexů. (protože selektivita obou polí je vysoká) Pokud je však TOC samotného DML 3 stránky a položka SELECT v indexu má pouze patnáct řádků, pravděpodobně byste přešli na druhý, a to je příklad, kdy těžíte z obou indexů.
Nyní, pokud si myslíte, že je to příliš přitažené za vlasy, vezměte v úvahu databázi naskenované knihovny kongresu. :)
Jak jsem řekl dříve, veškeré plánování je v pořádku, ale na konci spusťte své vlastní benchmarky.