2017-10-06 109 views
0

我們已將所有GTFS體系結構轉換爲Maria DB表。SQL查詢佔用100%CPU - Maria DB

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

所以我們有像 表 - 停止 - 行程 - stop_time的 - 等

然後我們有一個SQL查詢來查找當前停止後全部停止,所以我們使用以下查詢

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; 

然而,當我運行此查詢每個停下來在不同的表一旦填充它使用的結果本身牛逼後,不幸的是,CPU使用率達到100%

我不知道爲什麼,在此先感謝。

+1

這裏有很多連接,所以如果你有很多記錄,這可能會通過數十億行數據處理。 – tadman

+0

爲什麼不提供一些「樣本數據」和「預期結果」(請參閱​​https://stackoverflow.com/help/mcve)*現在您可能正在使用LEAD()OVER()現在您正在使用Mariadb * –

+0

@ tadman有什麼建議來優化查詢? –

回答

1

IN (SELECT ...),取決於版本的MySQL/MariaDB的的可以優化極差(即,CPU)。嘗試將其變成JOIN

AND t2.stop_sequence > t1.stop_sequence聞起來像做「GroupWise的最大」最糟糕的方式。這是它的一部分嗎?它是O(N * N)。有更快的方法。我發現的最快的是這裏。根據您的要求,它可以是O(N)或更好。

FROM (SELECT ...) JOIN (SELECT ...)也可以優化非常差 - 既不是「派生表」有一個索引,所以你將有多個表掃描(即,CPU)。我們來看看EXPLAIN SELECT ...,看它是否在派生表之一上表示All。要解決這個問題,可以考慮創建一個子查詢作爲TEMPORARY TABLE提供一個合適的索引。

而且,如前所述,如果你正在使用MariaDB的10.2,考慮完全重寫開窗和/或CTE技術,整個查詢。