Überlappung bei Zeiträumen
-
Michael E. schrieb:
Prüfe bereits beim Anlegen einer Session, ob für den User eine weitere Session existiert. Dadurch hast du die Kosten auf viele Anfragen verteilt und die Zeitintervallabfragen entfallen.
Das hatte ich befürchtet. Das ist nämlich leider nur über hacks realisierbar...
Aber Danke
-
Hacks? Was spricht denn gegen einen Trigger?
-
Was ist, wenn s1.start < s2.start und s1.end > s2.end. Dann bekommst Du das nicht mit. Da musst Du an Deiner Bedingung noch ein wenig feilen.
Ansonsten zur eigentlichen Frage bezüglich Performance: Hast Du den Query-plan angeschaut? Hast Du geeignete Indizes? Werden sie auch verwendet? Ein Index über "user, start" würde sich spontan anbieten.
-
Michael E. schrieb:
Hacks? Was spricht denn gegen einen Trigger?
Weil der Code nicht im livebetrieb läuft sondern nachträglich statistiken anfertigt.
Habe es jetzt im programmcode gemacht - ich lese die daten sortiert aus und kann dadurch recht trival doppelte sessions erkennen.
@ich bins:
alle meine versuche es per Query zu lösen liefen >10 Minuten. Die aktuelle Variante läuft in <20 sekunden. Also technisch nicht schön, aber dafür schnell genug. und ja: start, ende und user sind indices.
-
Shade Of Mine schrieb:
@ich bins:
alle meine versuche es per Query zu lösen liefen >10 Minuten. Die aktuelle Variante läuft in <20 sekunden. Also technisch nicht schön, aber dafür schnell genug. und ja: start, ende und user sind indices.Ich meinte einen Index über user, start, also einen kombinierten Index. Wenn Du auf jeder einzelnen Spalte einen Index hast, kann die Datenbank nur einen verwenden. Er wird nach user suchen und dann alle anfangen zu kombinieren. Bei user, start kann er weiter eingrenzen.
Nochmal: schau Dir den Query-plan an. Es kann eigentlich nicht sein, dass es mehr als 10 Minuten dauert. Na ja - bin kein Mysql Experte. Ich bevorzuge sowieso Postgresql. Warum man überhaupt Mysql verwendet, entzieht sich weitgehend meiner Kenntnis. Aber das ist eine andere Geschichte.
-
ich bins schrieb:
Nochmal: schau Dir den Query-plan an. Es kann eigentlich nicht sein, dass es mehr als 10 Minuten dauert. Na ja - bin kein Mysql Experte. Ich bevorzuge sowieso Postgresql. Warum man überhaupt Mysql verwendet, entzieht sich weitgehend meiner Kenntnis. Aber das ist eine andere Geschichte.
Auch mit einem kombinierten Index wird es nicht relevant schneller (also vielleicht schon aber immer noch viel zu langsam). Das Problem sind die multiplen Table Scans die er scheinbar braucht.
Aber wie gesagt: ich habe es nicht hinbekommen. Falls es doch geht wäre ich sehr an einer Lösung interessiert.
-
Shade Of Mine schrieb:
ich bins schrieb:
Nochmal: schau Dir den Query-plan an. Es kann eigentlich nicht sein, dass es mehr als 10 Minuten dauert. Na ja - bin kein Mysql Experte. Ich bevorzuge sowieso Postgresql. Warum man überhaupt Mysql verwendet, entzieht sich weitgehend meiner Kenntnis. Aber das ist eine andere Geschichte.
Auch mit einem kombinierten Index wird es nicht relevant schneller (also vielleicht schon aber immer noch viel zu langsam). Das Problem sind die multiplen Table Scans die er scheinbar braucht.
Aber wie gesagt: ich habe es nicht hinbekommen. Falls es doch geht wäre ich sehr an einer Lösung interessiert.
Ich glaube nicht, dass Dir jemand noch weiter helfen kann, wenn Du einfach sagst, "ich habe es nicht hinbekommen". Und noch ein 3. Mal: hast Du Dir den Query-Plan angeschaut? Wenn Du wirklich Hilfe möchtest, solltest Du mindestens mal folgende Angaben liefern:
- eine Tabellenbeschreibung (welche Spalten und welche Typen)
- alle angelegten Indizes
- ein Mengengerüst (wie viele Datensätze, wie viele Sessions pro user)
- einen Queryplan für den Request, den Du persönlich für den besten hälst
Hilfreich wären weiterhin möglicherweise die Mysql-Version und das verwendete Betriebssystem.
Eventuell hast Du ja einfach nur ein "update statistics" oder wie auch immer das bei MySQL heißt vergessen. Das könnte man möglicherweise im Queryplan erkennen. Mir ist es schon passiert, dass Queries länger als erwartet gelaufen sind und im Queryplan habe ich gesehen, dass die Datenbank einen Full-table-scan gemacht hat, da die Statistiken gesagt haben, die Tabelle ist klein, obwohl sie sehr groß war.
-
Das Problem ist, dass das Query so nicht funktionieren wird. Man braucht einen besseren Ansatz das Problem zu lösen als so einen primitiven Join.
-
Warum wird das nicht funktionieren? Also ich wüsste, wie man überlappende Zeiträume ermitteln kann. Und das mit einem "primitiven" join. Du musst nur die richtige Frage stellen
. Aber momentan bezieht sich Deine Frage nur auf die Performance. Und um die zu analysieren, braut es einen Query-Plan.
-
ich bins schrieb:
Warum wird das nicht funktionieren?
Wenn du das nicht weisst, dann kannst du mir auch nicht helfen
Aber danke für deine Mühen.