poprilično sati sam proveo optimizujući problematične upite na real-life bazama klijenata (jedna te ista aplikacija, samo drugi klijenti) i nikad, baš nikad, nisam video "index_merge" u explain-u. od merdžovanja indexa digao ruke, prešao na kompozitne indexe i, kao, "pođe me karta".
-----------------
jedan problem su mi upiti u kojima se vrte velike tabele (1 000 000+) slogova i gde se dinamički pravi SQL (where klauzula) pa ne znam unapred koje će kolone da se nađu u where klauzuli. na primer, uvek mi trebaju kolone C3, C4 ali se u where klauzuli nađe neka mutljavina:
SELECT DISTINCT C3, C4 WHERE C1='A' AND C2 IN ('X', 'Y', 'Z') AND C3 IN (1, 2, 16, 55) AND C5=12 AND C8 IN (8,18,32)
dakle, jedno 5 kolona u WHERE klauzuli od kojih 1 i u SELECT-u.
to trenutno rešavam kompozitnim indeksima i rekao bih da je prihvatljivo, mada mislim da može bolje.
-----------------
drugi problem su upiti koji se rasplinu po pola grafa pa imam 15 tabela u kojima se nešto JOIN-uje, WHERE-uje, itd. tu mi ni kompozitni indeksi nisu bili dovoljno dobri pa sam ih "ojačao" sa EXISTS/subSELECT umesto JOIN/WHERE, gde god sam mogao. imam utisak da je tako brže - više manjih upita umesto jednog kapitalca.
explain mi kaže da se uvek koristi neki index.
-----------------
ako neko ima neki tip u vezi ove 2 strategije, mikrofon je Vaš.
sad malo da kukam:
cena koju sam platio jeste da sam morao da migriram ID-jeve iz parent tabela u grand-child tabele (T0, T1, T2, pa se ID od T0 nađe u T2 da bih mogao da napravim kompozitni index).
nosim se mišlju da predložim redizajniram modela, što nije jednostavno (vreme za razvoj, migracija, QA, itd.), ili da pokupim i šta mi ne treba iz baze po sistemu "drpi i beži" pa da "krajcujem" u Java-i.
Acta, non verba!
koliko indexa po upitu koristi MySQL?