Query-Optimierung - Sortierung

[auhur]

Hallo,

ich habe folgendes Problem:

Script: Auf einer Seite werden einzelne Fotos aufgelistet. Diese Fotos besitzen jeweils einen Datenbankeintrag der eine Unique ID, publish (veröffentlichungsdatum als unix timestamp) und eine Kategorisierung (INT) aufweist.

Auf jeder dieser Fotoseiten befinden sich folgende Links: "<< letztes Bild | Alle Bilder der Kategorie | nächstes Bild >>". Die Aufgabe dieser Links sollte klar sein. Soweit hört sich das sicher noch sehr einfach an, komme ich mal zum

Problem: Die Fotos sollen nicht anhand der ID sondern anhand des Veröffentlichungsdatum (publish) in der richtigen Reihenfolge aufgelistet werden. Es kann vorkommen, das mehrere Einträge gleiche Daten-Timestamps aufweisen. Was ich für die Navigation demnach brauche, ist die jeweilige ID des vorhergegangenen und folgenden Bildes. Das Script läuft soweit. Nur sind die MySQL Prozesse dieser Funktion viel zu arbeitsaufwändig, da durch die Sortierung ja erst einmal tausende von unnötigen Datensetzen abruft!

Wie könnte man das optimieren?

SELECT
	id
FROM
	pictures
WHERE
	publish>='$aktuellerTS'
	AND id!='$aktuelleID'
	$q
ORDER BY
	publish ASC
LIMIT
	1

Den Query benutze ich ein zweites mal um auch die ID des vorhergegangenen Bildes abzurufen. Dann halt mit "...publish<=..." und "...ORDER BY publish DESC..."

Am besten wäre natürlich, wenn man aus den zwei Queries einen machen könnte. Nur glaube ich nicht, dass dies in einer Abfrage a la ...

SELECT id .... WHERE publish ~eine stelle kleiner ist als aktuellerTS ~ ORDER BY publish ASC LIMIT 3

... möglich wäre. Das wäre jedoch genau das was ich suche.

Problematisch ist, das die Tabelle aus über 50.000 Einträgen besteht und demnach bei jedem Scriptaufruf alle diese Einträge - ein Teil vorwärts , und der andere Teil rückwärts anhand des Timestamps des aktuell angezeigten Bildes - gescannt werden muss.

Ich hatte auch den Ansatz, ein Array aus den Datensätzen zu erstellen und PHP die Arbeit übernehmen zu lassen, indem ich mir immer die positionen raus suche, die ich grade brauche. Das ist aber kaum machbar, da die Bilder 5-6 verschiedene Kategorien aufweisen, für die jedesmal ein einzelnes Array erstellt werden müsste, welches sehr groß werden würde. Zudem kommen noch ständige Updates innerhalb der Tabelle.


Kann mir jemand helfen?


Bitte! :)

[stb]

Spalten, die in irgend einer Form mit WHERE oder JOIN in Verbindung gebracht werden, sollte man mit einem Index versehen. Dann sind Abfragen selbst über mill. Zeilen kein problem mehr.

Wenn du merkst, das deine Datenbank für eine Abfrage jedesmal die gesammte Datenbank durchsucht, dann brauchst du einen Index. Das ist ja gerade die Stärke der Datenbanken.

Denn sonst könntest du auch den ganzen Mist in eine simple Textdatei speichern und mit PHP durchsuchen...

[auhur]

danke. aber indizes sind natürlich gesetzt.

[stb]

Dann lass dir doch mal mit EXPLAIN SELECT... mehr infos über den Select geben.
Wenn MySQL für einen einfachen select jedesmal die ganze Tabelle durchläuft, funktioniert irgend ein Index nicht, oder du hast einen WHERE oder ON auf einer Spalte, die nicht indiziert ist.
Spalte publish (timestamp) z.B. sollte indiziert sein, weil ein Join drauf läuft...