MySQL, még mindig az indexek

Íratlan törvény, hogy a táblák kapcsolódási pontjaiból érdemes indexet csinálni. A Zandagort kódban ezt már korábban átnéztem. Viszont volt néhány query, ami viszonylag sok tábla kapcsolatából állt és egyre nagyobb részt vett ki a körváltóból, így utána kellett nézni, nem-e lehet gyorsabbá tenni.

Végig néztem a használt táblákat és volt már rajtuk index, szép számmal, több helyen már redundánsnak is tűntek. Próbáltam a lekérdezés WHERE feltételének sorrendjét módosítani, de kb. semmi változást nem hozott. Próbálkoztam az EXPLAIN EXTENDED és persze az SQL_NO_CACHE kombóval, hogy hátha valahol még lehet faragni. Látszólag mindenhol a PRIMARY KEY-eket használta, ami nekem úgy tűnt, hogy rendben van. Az egyetlen probléma az volt, hogy viszonylag nagy adatmennyiséggel kellett dolgoznia. Nézegettem a JOIN és WHERE feltételeket, úgy éreztem, hogy egyesével kell végignézni minden oszlopot. Ezek az oszlopok már szerepeltek kulcsokban, többségük PRIMARY KEY is, viszont találtam kettőt, ami csak többed magával szerepel kulcsokban. Látszólag nem volt értelme belőlük kulcsot csinálni, de egy próbát megért. A változás látszik a grafikon végén.

Egyik oldalt az esztelen kulcsgyártás van, a másik oldalt pedig a tapasztalatok és ajánlások szigorú követése. Sajnos eddig a részben esztelen kulcsgyártás áll nyerésre.

A nagy mennyiségű adatokkal való munka az adatbázisban már egy külön szakma lett szerintem. A 18 magos Xeon procik korában mindenki hajlamos az SQL-t sima adattárolónak használni, ráadásul hódítanak a NoSQL megoldások is, ami szerint pont az SQL optimalizációk miatt nem jó ötlet, kivéve, ha kis mennyiségű adattal kell dolgozni. Egy jól kioptimalizál SQL adatbázis nagy forgalom esetén egy $25-os robotos TV játékoson is gyorsabban tud futni, mint az optimalizálatlan változat egy 15 milliós szerveren.