2017-10-06 5 views
0

Wir haben alle GTFS-Architektur zu Maria DB-Tabellen konvertiert.SQL Query dauert 100% CPU - Maria DB

https://developers.google.com/transit/gtfs/examples/gtfs-feed

So haben wir Tische wie - stop - Reise - Stop_Time - etc

Dann haben wir eine SQL-Abfrage alle Register nach dem aktuellen Anschlag zu finden, so verwenden wir die folgenden Abfrage

SELECT DISTINCT t2.stop_id 
FROM (SELECT stop_id, 
       trip_id, 
       stop_sequence 
     FROM stop_time 
     WHERE stop_id IN :stopIds) t1 
     inner join (SELECT stop_id, 
          trip_id, 
          stop_headsign, 
          stop_sequence 
        FROM stop_time 
        WHERE trip_id IN (SELECT trip_id 
             FROM stop_time 
             WHERE stop_id IN :stopIds)) t2 
       ON t2.trip_id = t1.trip_id 
        AND t2.stop_sequence > t1.stop_sequence; 

Allerdings, wenn ich diese Abfrage für jede laufen stoppen sie in einer anderen Tabelle einmal füllen sie das Ergebnis se verwenden t später, leider geht die CPU-Auslastung auf 100%

Ich bin mir nicht sicher, warum, danke im Voraus.

+1

Es gibt eine Menge Joins hier, also wenn Sie viele Datensätze haben, könnte das durch Milliarden von Datenzeilen gehen. – tadman

+0

Warum liefern wir einige 'Beispieldaten' und das' erwartete Ergebnis' (siehe https://stackoverflow.com/help/mcve) * Vielleicht könnten Sie jetzt LEAD() OVER() verwenden, da Sie jetzt Mariadb * –

+0

@ verwenden tadman irgendwelche Vorschläge zur Optimierung der Abfrage? –

Antwort

1

IN (SELECT ...), abhängig von der Version von MySQL/MariaDB kann extrem schlecht (dh CPU) optimieren. Versuchen Sie es in eine JOIN zu verwandeln.

AND t2.stop_sequence > t1.stop_sequence riecht wie der schlechteste Weg, "groupwise-max" zu tun. Gehört es zu dem? Es ist O (N * N). Es gibt schnellere Wege. Die schnellsten, die ich gefunden habe, sind hier. Abhängig von Ihren Anforderungen kann es O (N) oder besser sein.

FROM (SELECT ...) JOIN (SELECT ...) kann auch schrecklich schlecht optimieren - weder 'abgeleitete Tabelle' hat einen Index, so dass Sie mehrere Tabelle Scans (dh CPU) wird. Mal sehen EXPLAIN SELECT ..., um zu sehen, ob es All auf einer der abgeleiteten Tabellen sagt. Um dies zu beheben, sollten Sie eine der Unterabfragen als TEMPORARY TABLEund mit einem geeigneten Index erstellen.

Und, wie bereits erwähnt, wenn Sie MariaDB 10.2 verwenden, erwägen Sie, die gesamte Abfrage mit Windowing und/oder CTE-Techniken komplett neu zu schreiben.