Abfrageoptimierung

[Tim Hildebrandt]

Hallo Sebastian,

> > Dann 
> > w�rde es Deiner Ausf�hrung nach mehr Sinn machen, einen Gesamtindex 
> > �ber die Spalten "Klickzeitpunkt, RubrikPfad, DokumentID, BildID" 
> > statt jeweils �ber die einzelnen Spalten zu erzeugen?
> 
> du brauchst einen Index �ber die Spalten die in der Abfrage 
> im ORDER, WHERE oder JOIN Teil vorkommen, und die Reihenfolge 
> ist nat�rlich auch noch relevant

Ist nur eine Tabelle und ausgewertet wird in der Regel nur eine Spalte
hinsichtlich eines begrenzten Zeitraums. 

 
> ... und wenn du eh ALLE Felder der Tabelle ben�tigst w�re der 
> Index selber ja genauso gro� wie die Tabelle ... weniger praktisch

nun ja, aber ich m�chte ja alles wissen. Und das m�glichst schnell... :-)


Das der Index da recht gro� wird, mu� ich wohl hinnehmen. Meine Idee
diesbez�glich ist es, die Tabelle in mehrere kleinere aufzuteilen und darin
immer nur die Daten der jeweiligen Zeit-Bereiche zu speichern. Ich �berlege
gerade, ob ich als begrenzenden Faktor da die tats�chliche Tabellengr��e
oder vielleicht sogar einfach nur die Monatszahlen verwende. Also vielleicht
"statistik_2006_06", "statistik_2006_07" u.s.w. und die Abfrage dann mittels
UNION anhand der tats�chlich abgefragten Zeitr�ume zusammensetze. Das w�re
auf jeden Fall besser als die Tabelle z.B. immer nur jedes Jahr neu beginnen
zu lassen, da bei einem Abfragebereich von z.B. 1.1.06 bis 28.2.06 nur zwei
Tabellen angefa�t werden m�ssten... und somit auch nur die darin vorhandenen
Datenmengen. Besonders vorteilhaft w�re das ggf. sogar, wenn der
Abfragebereich �ber die Jahresgrenze hinweg geschieht, also z.B: 25.12.05
bis 31.1.06, da auch hier nur zwei vergleichsweise kleine Tabellen
betrachtet werden w�rden. Was sagst Du dazu?


Gr��e
Tim

-- 
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql