millionen von datensätzen ...

Das scheint mir sehr ungewöhnlich, da er doch "nur" zwei Einträge mit organiser_id finden dürfte. Wie viele Datensätze erfüllen denn das Kriterium organiser_id IN (446, 14)?

Wenn es sehr viele sind, auch auch sehr viele über das Kriterium timestamp BETWEEN ... ausgewählt werden, dann kann es sinnvoll sein, einen zusammengesetzten Index aus organiser_id und timestamp zu bilden, da MySQL immer nur einen Index für eine Abfrage verwendet. Welcher Index benutzt wird, wird normalerweise intern optimiert. Wenn allerdings beide Indexe eine gleich große Ergebnismenge erzeugen, dann dauert's halt wieder länger.

Ich selbst habe knifflige Performanceprobleme auch immer sehr gut mit temporären Tabellen in den Griff bekommen. Das wäre dann die nächste Möglichkeit, wenn der Index allein nicht mehr hilft. Für deinen Fall könntest du zuerst alle Eintrage mit dem Kriterium "organiser_id IN (446, 14)" in eine temporäre Tabelle packen, danach aus diesen Daten das timestamp selektieren. Du musst dabei nicht alle Spalten in die temp-Table packen, nur die relevanten. Als Ergebnis solltest du die gewünschten primary-keys erhalten, aus denen du dann über einen JOIN mit der Original-Tabelle die eigentlichen Daten herausziehen kannst.

Mehr Infos zur Arbeit mit temporären Tabellen in MySQL findest du hier:
http://www.heddesheimer.de/coaching/mysql_group.html

Gruß Marian
 
Noch ein Perfomanztip:

Mach 2 MySQL Server! Einer der update, insert und delete organsiert und einer von dem gelesen wird!

ALso so:
Master = Schreibende Zugriffe
Slave = nur lesende Zugriffe

Vorteile:
1. Skalierung der Last
2. Unterschiedliche Configs ermöglichen angepasstere Caching im RAM
3. Ausfallsicherheit ....

Ansonsten sind schon viele gute Tips gegeben wurden. :-D

Chris
 

Neue Beiträge

Zurück