Indexujte to, co se zdá nejlogičtější (to by snad mělo být zřejmé, například sloupec ID zákazníka v tabulce CUSTOMERS).
Poté spusťte aplikaci a pravidelně sbírejte statistiky, abyste viděli, jak si databáze vede. RUNSTATS na DB2 je jedním příkladem, doufám, že MySQL má podobný nástroj.
Když zjistíte, že některé často spouštěné dotazy provádějí úplné prohledávání tabulky (nebo to trvá příliš dlouho z jiných důvodů), pak a teprve potom , měli byste přidat další indexy. Optimalizace dotazu spouštěného jednou za měsíc o půlnoci tak, aby mohl skončit ve 12:05 místo ve 12:07, příliš nepomůže. Obrovským zlepšením je však zkrácení dotazu pro zákazníka z 5 sekund na 2 sekundy (to je stále příliš pomalé, dotazy pro zákazníky by měly být pokud možno méně než sekundy).
Více indexů má tendenci zpomalovat vkládání a urychlovat dotazy. Jde tedy vždy o balancování. Proto přidáváte indexy pouze v konkrétní reakci na problém. Cokoli jiného je předčasná optimalizace a je třeba se tomu vyhnout.
Kromě toho pravidelně kontrolujte indexy, které již máte, abyste zjistili, zda jsou stále potřeba. Je možné, že dotazy, které způsobily, že jste tyto indexy přidali, již nejsou spouštěny dostatečně často, aby to opravňovaly.
Abych byl upřímný, nevěřím, že indexování tří sloupců v tabulce vám způsobí utrpení, pokud neplánujete ukládat opravdu velké množství řádků :-) - indexování je docela efektivní.
Po úpravě, která uvádí:
Moje odpověď je, že 200 záznamů denně je pro databázi extrémně malá hodnota, s těmi třemi indexy se rozhodně nebudete mít čeho bát.
Zrovna tento týden jsem do jedné z našich databázových tabulek v práci importoval transakce v hodnotě dní a obsahoval 2,1 milionu záznamů (získáme alespoň jednu transakci za sekundu za celý den z 25 samostatných strojů). A má čtyři samostatné složené klávesy, což je poněkud intenzivnější než vaše tři samostatné klávesy.
Připouštím, že je to na databázi DB2, ale nedokážu si představit, že IBM je tak mnohem lepší než lidé s MySQL, že MySQL zvládne pouze méně než 0,01 % zátěže DB2.