Queries optimaliseren bij ophalen data

Hey!

Ik ben bezig met een project, en daar moet ik van bepaalde dagen de count ophalen van het aantal logbestanden dat is aangemaakt. hier maak ik dan een grafiek van.

De grafieken zijn als volgt:
Aantal logs per dag, voor deze week
Aantal logs per dag, voor deze maand
Aantal logs per maand, voor dit jaar.

Op het moment doe ik dit met verschillende queries:

SELECT 
                              count(LOG_ID) AS SESSION_COUNT, 
                              DAYOFWEEK(LOG_DATE) AS SESSION_DAY 
                            FROM 
                              LOG 
                            WHERE 
                              WEEK(LOG_DATE) = WEEK(NOW())
                            GROUP BY 
                              DAYOFWEEK(LOG_DATE) 
                            ORDER BY 
                              SESSION_DAY

SELECT 
                              count(LOG_ID) AS SESSION_COUNT, 
                              DAYOFMONTH(LOG_DATE) AS SESSION_DAY 
                            FROM 
                              LOG 
                            WHERE 
                              MONTH(LOG_DATE) = MONTH(NOW())
                            GROUP BY 
                              DAYOFMONTH(LOG_DATE) 
                            ORDER BY 
                              SESSION_DAY

Maar ik merk dat de database op deze manier relatief veel werkdruk heeft (pageload van 0.8 t.o.v. pageloads van 0.05).

Iemand een suggestie hoe ik dit beter kan doen?

- Rik

1x per nacht deze query uitvoeren en dan gewoon de data in de database opslaan?

Jellet schreef:

1x per nacht deze query uitvoeren en dan gewoon de data in de database opslaan?

De eis is dat het realtime moet zijn.

Asynchroon inladen? Dan kan je een halve seconden een laad iets tonen en dan de data inladen.
Daarna de data direct cachen met een timestamp van 10 minuten - 30 minuten (licht eraan hoe realtime het moet zijn)
Dan heb je eens in de 10-30 minuten een halve seconden dat je langer moet wachten ofzo.

Maar er is geen betere methode van ophalen? Want zo verplaats je eigenlijk het probleem alleen maar.

indexeren?
Verder geen idee wat er mis kan zijn met zon query of hoe je het beter kan doen.

Laten tellen door PHP ipv MySQL?

Je zou wat kunnen denormaliseren door de uitkomst van WEEK() en DAYOFWEEK() apart in je tabel op te slaan. De WHERE wordt dan bloedsnel omdat hij niet voor elke rij WEEK(LOG_DATE) hoeft te doen, maar gewoon een getal in de tabel kan checken. Het zelfde geldt uiteraard voor DAYOFWEEK(LOG_DATE) in de GROUP BY. Zeker als je daar dan nog eens een goede (!) index op zet, dan moet het stukken sneller zijn.

Voor je tweede query geldt hetzelfde, maar dan voor MONTH() en DAYOFMONTH().

Nadeel is dan dus wel dat je zit te denormaliseren, maar op een andere wijze optimaliseren gaat niet lukken denk ik zo, tenzij je op dit moment geen goede (!) indexen hebt, dan zou je dat nog kunnen proberen.

Alles helemaal door normaliseren is lang niet altijd goed en / of chill.
Soms is het juist beter om iets minder te normaliseren om daardoor (bijv in dit geval) de performance te verbeteren.

Op zich is 0.8 seconden nog wel te doen, maar ik vroeg me gewoon af of het beter kon.

Indices kan ik inderdaad nog wel een keer naar kijken, heb het gevoel dat ik die hier vergeten ben.

Als je log-tabel momenteel data van meerdere jaren bevat, dan worden de maanden bij elkaar opgeteld. Dat is op te lossen door [c]YEARWEEK(date)[/c] te gebruiken ipv [c]WEEK(date)[/c]
Het lijkt me iig beter om in de WHERE te zoeken op data die groter/gelijk zijn aan de eerste dag van de week (of maand). Anders wordt er onnodig een weeknummer berekend voor rijen die je niet gebruikt.

Mogelijk slechte indexes ja. Heb je al eens een [c]EXPLAIN[/c] query gedaan om te kijken wat de bottleneck is?