Optimering schmoptimering
Det har varit en helg med svett och tårar ska du veta. Halva helgen har kantats med feber, andra halvan av optimeringsarbete med MySQL:s processlista på ena skärmen och Apaches processlista på den andra. Jag har dykt i scriptfiler, prövat varianter på databasfrågor och vridit och vändit på det mesta känns det som.
Förutom klassiska fallgropar (EXISTS med subquery är snabbare än IN, men subqueries överlag är nasty evil) verkar det som att vi helt enkelt står inför en hårdvaruuppgradering. Man kan dock alltid optimera lite till, vilket jag också gjort under kvällen och sajten känns i alla fall lite snärtigare. Framför allt handlade det om en viss typ av db-fråga som fastnade i slowlog, som användes dels på spelsidorna och dels i den lilla ruta som ploppar upp om du klickar på ett kugghjul på ett spel på framsidan.
Frågan var av typen:
SELECT COUNT(*) FROM gec_images WHERE in_album IN ( SELECT aid FROM gec_albumgames WHERE gid = '1796' OR ( gid IN ( '1796', '4189', '4190', '4191' ) AND allplat = '1' ) );
...vilken kunde ta så mycket som 30-40 sekunder att köra under högpress - trots att tabellerna i fråga har rätt index på plats. I det här fallet skrev jag om frågan i flera led. Nu fastnar i alla fall inga queries i slowlog för stunden.
Lite kuriosa: Databasservern snittar på 1000 frågor i sekunden. Det är inte illa.
Kan nämna att vad frågan gör är att räkna antal bilder som tillhör ett visst spel, eller dess syskon (spelkloner på andra plattformar).
MySQL är inte så duktigt på att hantera subselects, så i ett läge som detta kan man ofta vinna prestanda genom att ställa den inre frågan först, konvertera resultatet till en lista och stoppa in den i frågan. Frågan blir lång och ful men det gör inte så mycket, för den blir väldigt snabbparsad.