[MySQL, UniDAC] Query vorzeitig abbrechen?

[Sir Rufo]

Das du auf das Ende aller Threads warten musst, liegt natürlich auch daran, dass du einen Löck von deinem Chart-Objekt in jedem Thread verwendest.

Den "Throttle" würde ich auf jeden Fall auch verwenden, die Threads würde ich aber unabhängige Listen erstellen lassen und erst zum Abschluss diese Listen an das eigentliche Objekt zurückliefern.

Das sollte dein Problem im Prinzip lösen.

[zagota]

Bei den UniDAC-Komponenten gibt es die Möglichkeit FetchAll = False zu setzen.
Vielleicht hilft dir das weiter.

cu

[Medium]

Zitat von Sir Rufo:

Das du auf das Ende aller Threads warten musst, liegt natürlich auch daran, dass du einen Löck von deinem Chart-Objekt in jedem Thread verwendest.

Der Lock betrifft nicht die ganze Abfrage, sondern nur diesen kleinen Block hier:

Delphi-Quellcode:

    FChart.FSeriesLock.Enter;
    try
      if Assigned(FChart.FSeries) then
        FreeAndNil(FChart.FSeries);
      FChart.FSeries := tmpSeries;
    finally
      FChart.FSeriesLock.Leave;
    end;

Es wird also im Thread erst eine temporäre Liste erstellt, die dann mit einer einfachen Referenzzuweisung an das Chart gegeben wird. (Und vorher die alte freigegeben natürlich.)
Theoretisch könnte ich das einfach laufen lassen und nachher nur per gesetztem Abort-Flag das Umhängen der Liste unterlassen bei abgebrochenen Threads. Ich hatte aber gehofft die gerade beim Scrollen mit der Maus dann schnell erzeugten 10-20 Queries die dann ja noch laufen der DB nicht zumuten zu müssen, die vor allem ja auch noch weiterhin sekündlich neue Daten die von einer Server-Applikation kommen wegschreiben muss. Fand's einfach unschön.
Die Verlangsamung kam dadurch, dass ich versucht habe den Thread aus dem Hauptthread heraus sauber inmitten einer SQL-Query abzubrechen - was scheinbar ein Ding der Unmöglichkeit ist.

Zitat:

Das sollte dein Problem im Prinzip lösen.

Im Prinzip tut es das auch, aber eben mit dem kleinen Nachteilchen, dass die DB unnötig weiterrödeln muss. Dank des "Throttles" dürfte das jetzt allerdings deutlich weniger und seltener sein, so dass ich mal probieren könnte auf KillThread() ganz zu verzichten!

@zagota: Wenn ich das richtig verstehe begrenzt das lediglich die Anzahl der Datensätze die übertragen werden. Die Query muss aber trotzdem vorher vollständig ausgeführt werden. Bei mir sind nicht große Datenmengen das Problem (maximal ~1000 Sätze pro Result, meistens eher um 500), sondern die Queries selbst.
Ich habe hier schon, für das was sie tut, wirklich gute Geschwindigkeiten. Dinge wie "Ermittle aus sekündlichen Messdaten den Durchschnitt, Minimum und Maximum für Zeitabschnitte von je X Sekunden und Y Minuten, gruppiert nach Zeitabschnitten, und das Summiert aus 3 (von ca. 500) Tabellen mit je knapp 8mio Datensätzen (bisher), im Zeitraum von 01.01.2016 bis 01.02.2016. In, je nach dem wie günstig man den Server gerade erwischt, 1-2 Sekunden, manchmal sogar drunter.) Gemessen an der Aufgabe ist das echt gut, aber zum immer vollständig neu Updaten beim herumscrollen und zoomen ist es zu langsam.
Die konkreten Zeitabschnitte ermittle ich aus der Breite des Charts, so dass niemals mehr als 1 Datensatz im Result pro Pixel Breite anfällt. Zu den sekündlichen Daten führe ich in den gleichen Tabellen auch die minütlichen und stündlichen bei jedem Update mit, die ich selektiere wenn 1px >= 1min bzw. Stunde ist. Bis auf die o.g. Kleinigkeit klappt das erfreulich gut. (Ja, die nötig werdende jährliche Festplattenarchivierung ist allen Beteiligten klar. Das ist i.O. (Das Datenbank-File hat jetzt schon, nach etwa 3,5 Monaten, ca. 150GB ))

[zagota]

Zitat von Medium:

@zagota: Wenn ich das richtig verstehe begrenzt das lediglich die Anzahl der Datensätze die übertragen werden. Die Query muss aber trotzdem vorher vollständig ausgeführt werden. Bei mir sind nicht große Datenmengen das Problem (maximal ~1000 Sätze pro Result, meistens eher um 500), sondern die Queries selbst.

Habe ich nicht versucht, bei einer Sortierung wird die Query sicherlich vollständig ausgeführt.
cu