Hallöchen,
ich habe mal eine Frage an alle Datenbankspezialisten da draußen. Ich habe eine
Query, welche für den Anwender viel zu lange dauert, insbesondere wenn diese Abfrage mehrmals ausgeführt wird, z.B. aufgrund von Refreshs o.ä... Die Abfrage wurde bereits mit Hilfe von Analyze optimiert, allerdings bin ich nun mit meinen Kenntnissen an einem Punkt angekommen, wo ich keine Ideen mehr habe.
Beschreibung: Die unten aufgeführte Abfrage soll es ermöglichen, zu einem Katalogteil dessen Menge im Lager je Station zu finden. Die Abfrage funktioniert inhaltlich einwandfrei, allerdings ist aufgrund der mittlerweile angefallenen Daten eine Abfragedauer von ca. 30 Sekunden zustandegekommen. Ich führe das Statement beim ersten Zugriff einmalig aus und nutze es dann die gesamte Sitzung über. Bei Daten-Refreshs, sprich wenn sich Daten diese Abfrage betreffend geändert haben, dauert die Abfrage allerdings wieder ewig, was relativ oft vorkommt. Weitere Gegebenheiten sind:
Zeilen mtx_stockparts: 100.000
Zeilen mtx_catalogparts : 250.000
Zeilen cd_stations : 50
Query:
select sp.id_catalogpart AS "id", sp.id_station AS "id1", sp.id_location AS "id2", sum(sp.quantity) AS "count"
from mtx_stockparts sp, mtx_catalogparts cp, cd_stations st
where sp._entrytype = 0
and st._deletedat is null
and sp._deletedat is null
and sp.id_station = st.id
and sp.id_catalogpart = cp.id
group by sp.id_catalogpart, sp.id_station, sp.id_location
Analyze-Auszug:
"GroupAggregate (cost=82456.84..85899.37 rows=32866 width=85) (actual time=9359.633..12518.661 rows=208288 loops=1)"
" -> Sort (cost=82456.84..83063.18 rows=242536 width=85) (actual time=9359.131..10720.273 rows=208667 loops=1)"
" Sort Key: sp.id_catalogpart, sp.id_station, sp.id_location"
" Sort Method: external merge Disk: 19960kB"
" -> Hash Join (cost=14957.97..49158.61 rows=242536 width=85) (actual time=1115.546..5276.611 rows=208667 loops=1)"
" Hash Cond: (sp.id_catalogpart = cp.id)"
" -> Hash Join (cost=3.94..20942.70 rows=242536 width=85) (actual time=0.893..1823.669 rows=208687 loops=1)"
" Hash Cond: (sp.id_station = st.id)"
" -> Seq Scan on mtx_stockparts sp (cost=0.00..17603.89 rows=242536 width=85) (actual time=0.074..655.781 rows=234393 loops=1)"
" Filter: ((_deletedat IS NULL) AND (_entrytype = 0))"
" -> Hash (cost=3.45..3.45 rows=39 width=27) (actual time=0.708..0.708 rows=39 loops=1)"
" -> Seq Scan on cd_stations st (cost=0.00..3.45 rows=39 width=27) (actual time=0.030..0.328 rows=39 loops=1)"
" Filter: (_deletedat IS NULL)"
" -> Hash (cost=10779.68..10779.68 rows=215868 width=27) (actual time=1114.393..1114.393 rows=215868 loops=1)"
" -> Seq Scan on mtx_catalogparts cp (cost=0.00..10779.68 rows=215868 width=27) (actual time=0.010..530.099 rows=215868 loops=1)"
"Total runtime: 12995.986 ms"
Wer hätte Vorschläge zur Optimierung dieser
Query oder den beteiligten Tabellen? Ich bin speziell darauf aus,
Query und Tabllen/
DB zu optimieren weil sich die Daten tendenziell noch verzehnfachen werden (riesige Katalog/Artikeldatenbanken), es sei denn jemand hat noch eine bessere Idee. Es wurden bereits einige Tests gemacht, immer "on demand" je Katalogteil zu laden, was allerdings unterm Strich dann beim Navigieren noch länger dauert und für den Anwender kein zufriedenstellendes Ergebnis lieferte. Ich bin für jeden Tipp und Hilfe dankbar
Viele Grüße
Seb