lomtas

Hallo,

momentan optimiere ich gerade eine selbst gebastelte Besucherstatistik. Diese liefert mir schon die Sachen, die ich gerne hätte, jedoch sind meine Abfragen zu langsam. Deswegen versuche ich gerade die Zeiten zu optimieren. Habe nun folgende Struktur:

Es gibt eine Besuchertabelle in die jeder Besucher eingetragen wird (momentan 15000 Einträge). Es werden einige Daten mitgeloggt. Unter anderem auch der Referer und der User_agent. Diese werden allerdings ausgelagert in extra Tabellen. Also habe ich drei tabellen: cms_besucher, cms_referer und cms_browser (für die user-agents).

Nun möchte ich herausbekommen, an welchem Tage ich die maximale Besucheranzahl hatte und wie viele das waren. Dafür habe ich folgende Abfrage:

Dann brauche ich eigentlich nur noch den obersten Eintrag nehmen und schon habe ich die gebrauchte anzahl. Er rechnet mir bei diesem Beispiel für jeden Tag die maximale Zahl aus und sortiert diese dann. Je mehr Tage es werden, desto länger dauert die Prozedur. Momentan bin ich alleine für diese Berechnung bei 0,3 Sekunden.

Weiß jemand Rat. Sieht jemand vielleicht Möglichkeiten meine MySQL-Abfrage zu verbessern? Bin für jede Hilfe dankbar!

Mister Ad

Waq

mach mal ein EXPLAIN auf das SELECT:
http://dev.mysql.com/doc/mysql/de/explain.html

Was sagt das?

__________________
mod = master of disaster

lomtas

Das Explain sagt folgendes:
cms_referer
type: ALL
possible keys: PRIMARY
key: NULL
key_len: NULL
ref: NULL
rows: 667
Extra: Using where; Using temporary; Using filesort
cms_besucher
type: ref
possible keys: INDEX,INDEX2
key: INDEX2
key_len: 5
ref: cms_referer.referer_id
rows: 22
Extra: Using where
cms_browser
type: eq_ref
possible keys: PRIMARY
key: PRIMARY
key_len: 4
ref: cms_besucher.browser_id
rows: 1
Extra: Using where

Waq

Erstmal scheint der Index auf cms_referer unzureichend, ich schätze, Du brauchst da nen multi-column-Index, der auch isrobot und showlink abdeckt. Das Problem ist behoben, sobald EXPLAIN zu cms_referer nicht mehr "key: NULL" sagt.

Dazu fällt mir noch ein, dass man zur Laufzweit berechnete Daten wie z.B. date_format(datumzeit, '%Y-%m-%d') nicht für Vergleiche (oder Sortierungen oder oder...) verwenden sollte, sondern nur Daten, die in einem nutzbaren Index stehen.

__________________
mod = master of disaster

lomtas

also wenn ich dich richtig verstanden habe, muss ich nun einen index für isrobot und für showlink anlegen?

wie kann man außer mit date_format noch das datum aus datumzeit rausholen, denn das brauche ich ja für meinen vergleich. oder soll das heißen, dass der typ datetime von mysql eigentlich schwachsinn ist und man eigentlich zwei felder anlegen sollte: eines vom typ date und eines vom typ time??

Waq

Einen multi-column auf referer_id, isrobot und showlink, wenn ich das richtig verstanden habe, ohne die Tabellendefinitionen vor der Nase zu haben ist das ein wenig Raterei.

Generell nein, wobei Du auch erstmal gucken solltest, wie weit dich der Index bringt, bevor Du ein eigenes Feld nur für das Datum anlegst.

__________________
mod = master of disaster

lomtas

Das Problem ist aber, dass referer_id und showlink in der einen tabelle sind und isrobot in der anderen. Kann man da auch einen multicolumn index anlegen?

lomtas

mit index anlegen und so bin ich jetzt auf 0,16 sek.

das ist schon mal gut. aber eigentlich müsste es doch noch schneller gehen.

momentan sagt er leider immer noch null...

lomtas

also, mal eine kleine auflistung, damit du auch weißt, wie es momentan mit den Indexes aussieht:

cms_besucher
besucher_id (PRIMARY)
browser_id (INDEX)
referer_id (INDEX)
datumzeit (INDEX)
cms_browser
browser_id (PRIMARY)
isrobot (INDEX)
cms_referer
referer_id, showlink (PRIMARY)
group_id (INDEX)

Ist das so okay, oder sollte ich was ändern?

Waq

Gut ist es, wenn auf allen Tabellen Indizes verwendet werden.

__________________
mod = master of disaster