mrSpok

hallo forum,

seit einiger zeit bin ich auf der suche nach optimierungen von 'WHERE datetime-feld' abfragen. leider habe ich bis jetzt noch keine lösung gefunden - aber vielleicht könnt ihr mir weiterhelfen.

vorab: ich bin nicht der administator der datenbank und kann somit nicht ins design eingreifen...

also die abfrage lautet in etwa wiefolgt:

problem ist leider die grösse dieser tabelle (>5mio zeilen) - eine solche abfrage dauert ca. 2000sek

kenn jemand eine möglichkeit solche abfragen performanter zu gestalten - also beispielsweise mit php nachzubearbeiten?

danke schonmal im voraus!

Mister Ad

Zergling-new

- ein LIMIT ist immer sehr hilfreich, wenn du maximal X oder genau Y Ergebnisse brauchst
- du kannst die Spalten ruhig auch selektieren wenn du sie überhaupt brauchst, denn die Zeile hast du ja sowieso schon getroffen

LetzteAenderung ist vom Typ Datetime?
Was genau enthält $StartDateTime der Form nach?

mrSpok

hi zergling,

danke für die schnelle antwort!

das ergebnis beinhaltet durchschnitlich 1000 zeilen.
hm.. müsste ich mal checken!
also mache zuerst ein MAX(meinPrimaryKey), packe die abfrage in eine schleife welche zusätzlich ein ' AND meinPrimaryKey>$x AND meinPrimaryKey<$y' beinhaltet. um dies danach wieder mit php in ein einzelnes array zu schreiben? das wäre sicher ein versuch wert!

das verstehe ich nun nicht ganz? meinst du zusätzliche spalte? die brauch ich nicht... ja, ich weiss - komische abfrage - dahinter steckt aber ein monitoring....

danke!

mrSpok

$StartDateTime enthält ein datetime wert :wink:

also zb: '2006-03-14 11:00:54'

grz

Dann auf jeden Fall einen Index über LetzteAenderung erstellen.

Was Du da mit $x und $y machen willst, klingt mindestens seltsam, eher falsch, wahrscheinlich sehr falsch.
Von Zergling gemeint war eine Abfrage der Form
SELECT ... FROM ... WHERE ... ORDER ... LIMIT x,y - sofern auf das Problem anwendbar.
Spätestens beim Wort "Schleife" ist in 99 von 100 Fällen ein Fehler im Datenbankzugriff oder -design anzunehmen.

mrSpok

LetzteAenderung ist leider auch teilweise NULL - vorallem aber fehlen mir die nötigen rechte sowas zu ändern...

ja, aber limit bringt doch bei solch einer abfrage nichts - limit wird doch auf das ergebnis angewendet? oder?

das verstehe ich nun nicht ganz?
diese datenbank wurde für den zweck designed, für welchen sie auch eingesetzt wird. ich versuche das ganze zu monitoren.. evtl. müsste ich wohl doch mal mit dem admin sprechen...:wink:
aber vergesst nicht - wir sprechen hier von >5mio zeilen - nach meiner erfahrung ist es in dieser dimension effizienter 500'000 abfragen zu starten als eine einzelne.

teilweise NULL Werte stören mysql nicht beim Indizieren. Die notwendigen Rechte sind da schon eher ein Problem. Ja, Admin fragen. Der Platzbedarf ist sicherlich ewiglangen Anfrage-Bearbeitungen vorzuziehen. Wenn es ein ausgewiesener DB-Admin ist, sollte er eh früher oder später auf Dich zukommen wegen des fehlenden Index, wenn Du den Server damit 2000 Sekunden beschäftigen kannst.
Deshalb das: sofern auf das Problem anwendbar.

Habe ich nie bezweifelt.Wenn das Design stimmt, greift vielleicht der erste Teil der Aussage? Abfrage-Schleifen sollen vermieden werden. Jede Abfrage kostet Extra-Zeit. Meistens ist auch die zusammengestoppelte Abfrage komplexer in der Abarbeitung als die eigentlich richtige Abfrage.
Sollte eine Schleife tatsächlich unvermeidbar sein, kann das Datenbankdesign (und sei es auch nur für diese eine Aufgabe) ungeeignet sein. Ist das Datenbankdesign nicht zu verbessern, liegt der 1 von 100 Fällen vor. So einfach ist das.

Das ist entweder schon lange her oder das Datenbanksystem (oder die Hardware?) taugt nichts oder es wurde sub-optimal genutzt - zB durch fehlende Indizes, unnötige Typkonvertierung bei Vergleichen, fehlerhaften WHERE/ON-Bedingungen oder oder oder.
Wenn Du durch einen einzelnen, einfachen Datumvergleich aus 5 Millionen Datensätzen 1000 auswählst, dann ist das keine schlimme Aufgabe für eine Mysql Datenbank.

Zergling-new

Du kannst das Ergebnis ja eventuell auch cachen, also jede Nacht generieren lassen und nur auf diese Werte zugreifen.

mrSpok

guten morgen..
stimmt - denk ich auch!



nun dies ist ein mysql-replication-server - und hardwaremässig nicht gerade optimal bestückt.. aus diesem grunde auch das problem mit grösseren abfragen - 1gb ram reichen nicht aus... bei dieser abfrage beginnt der server zu swappen.... das hardware-upgrade hat also höchste prio!

die abfrage selbst ist dieselbe, mal abgesehen von den den feld und tabellennamen, ich benötige nur den primary-key...

bezüglich schleifen:
ich habe nun kurz einen test gemacht mit einem hochzählenden 'limit' von 5000 Zeilen - Dauer: 6367.34721 sek (inklusive array auslesen, gruppieren) - schade! nur einen vorteil sehe ich - die Tabelle ist nicht wirklich lange 'locked', dies bleibt also eher unbemerkt! nachteil - diese abfrage sollte mal stündlich ausgeführt werden - passt so nicht rein...

Wenn ich dich richtig verstanden habe, mache ich dies bereits. Die abfrage wird ein einem Script weiterverarbeitet und in eine andere Datenbank geschrieben. Diese Abfrage sollte aber eigentlich jede Stunde durchgeführt werden... und da ist es schlecht, wenn die Tabelle jedesmal für 30 min Locked ist.

Eine kleine Optimierung habe ich inzwischen gefunden!
ist ca. 200 sekunden schneller :wink:


btw: Langsam frag ich mich ob ich nicht sauberer ist auf die Binlogs des Replicant zugreife um diese mehr oder weniger Realtime weiter zu verarbeiten...

danke für eure hilfe! ich werde bald mal alle unnötigen dienste stoppen um etwas speicher freizugeben und die abfragen nochmal laufen lassen - mal sehen!
grz