最大數量與數量查詢的巨大性能差異

-1

我必須進行類似的查詢，唯一的區別是一個人正在做一列的總和，另一個正在做另一列的計數（不同）。第一個以秒爲單位運行（17s），另一個從不停止（1小時計數）。我已經看到了計數查詢的計劃，並且它有巨大的成本。我不明白爲什麼。他們擊中完全相同的意見。爲什麼會發生這種情況，我該怎麼辦？最大數量與數量查詢的巨大性能差異

的一個運行良好：

select a11.SOURCEPP SOURCEPP, 
    a12.DUMMY DUMMY, 
    a11.SIM_NAME SIM_NAME, 
    a13.THEORETICAL THEORETICAL, 
    sum(a11.REVENUE) WJXBFS1 
from CLIENT_SOURCE_DATA a11 
    join DUMMY_V a12 
     on (a11.SOURCEPP = a12.SOURCEPP) 
    join SIM_INFO a13 
     on (a11.SIM_NAME = a13.SIM_NAME) 
where (a13.THEORETICAL in (0) 
and a11.SIM_NAME in ('ETS40')) 
group by a11.SOURCEPP, 
    a12.DUMMY, 
    a11.SIM_NAME, 
    a13.THEORETICAL

的一個不運行：

select a12.SOURCEPP SOURCEPP, 
    a12.SIM_NAME SIM_NAME, 
    a13.THEORETICAL THEORETICAL, 
    count(distinct a12.CLIENTID) WJXBFS1 
from CLIENT_SOURCE_DATA a12 
    join SIM_INFO a13 
     on (a12.SIM_NAME = a13.SIM_NAME) 
where (a13.THEORETICAL in (0) 
and a12.SIM_NAME in ('ETS40')) 
group by a12.SOURCEPP, 
    a12.SIM_NAME, 
    a13.THEORETICAL

來源

2015-11-19 Powernerd

發佈的查詢不*使用相同的表和視圖。 –

您的查詢不一樣。 'JOIN'到'a12'很可能會刪除很多行。如果您想比較性能，請在其他*相同*的查詢上進行比較。 'COUNT（DISTINCT）'通常比其他聚合速度慢一點，但我不認爲它是造成如此大的性能差異的唯一原因。 –

你正在比較蘋果和橘子。第一個查詢是按4列分組，而第二個查詢按3列分組。這些查詢是不一樣的。 – krokodilko

DISTINCT很慢的時候也有很多不同的值，數據庫需要SORT/HASH並將所有值（或集）存儲在內存/臨時表空間中。而且它使並行執行更難以應用。

如果有一種方法可以在不使用DISTINCT的情況下重寫查詢，那麼您一定要這樣做。

來源

2015-11-19 18:46:21 Husqvik

如上所述，DISTINCT必須執行表掃描，然後對數據進行散列，聚合和排序。這會增加電路板上的時間（CPU，磁盤訪問以及返回數據所需的時間）。如果可能，我會建議嘗試使用子查詢。這將限制聚合執行僅限於您想要區分的數據，而不是讓引擎在所有數據上執行它。例如，在實踐中如何實現這個功能，請參考Here's an article。

來源

2015-11-19 20:36:23 KOsterhout

最大數量與數量查詢的巨大性能差異

回答

相關問題