![]() |
Datenbank: FB • Version: 1.5, 2.0 • Zugriff über: egal
Performance-Prob mit Subselect
Hallo #,
ich habe folgende Tabellen project: project_id, projekt_state pos: pos_id, project_id, pos_state booking: booking_id,project_id except_projects: except_projects:_id,project_id in projects stehen Projekte (wer hätte das gedacht), in pos stehen Projekt-Positionen, in booking Projekt-Buchungen. Ich möchte jetzt alle Buchungen der Projekte/Positionen, die nicht in except_projects stehen
SQL-Code:
es werden noch Stati abgefragt (project_state, pos_state)
Select Booking.booking_id,Booking.project_id From Booking
Join Project On Project.project_id=Booking.project_id Join Pos On Pos.project_id=Project.project_id where Booking.project_id not in (Select except_projects.project_id From except_projects) Hm, soweit so gut, jetzt habe ich aber ein massives Performance-Problem. 10 sec. Prepare, 10 sec. Fetch (lokal) except_projects: 160 Einträge, aber 9 Mio. ausgelesen project:: 195 Einträge, 80.000 mal ausgelesen pos:: 4000 Einträge, 80.000 mal ausgelesen Im Plan sind nur Index-Scans, kein natural. Wie könnte ich die Abfrage ändern ? Edit: ===== Das ganze als SP dauert komplett nur 3 Sekunden, also wieder SP basteln ;( Heiko |
Re: Performance-Prob mit Subselect
Ich kenn mich mit Firebird nicht besonders aus, aber bringt es vielleicht was, die Abfrage so zu gestalten?
SQL-Code:
Überhaupt klingt das Problem sehr merkwürdig :gruebel: Ist FB vielleicht so eingestellt, keine temporäre Tabellen oder ähnliches für solche Queries anzulegen?
select s.b_id, s.p_id from
(Select Booking.booking_id as b_id,Booking.project_id as p_id From Booking Join Project On Project.project_id=Booking.project_id Join Pos On Pos.project_id=Project.project_id ) as s where s.p_id not in (Select except_projects.project_id From except_projects) |
Re: Performance-Prob mit Subselect
Hallo,
und nun das ganz gemeine, die Query ist nur unter FB2 (die aktuellste) so extrem langsam, unter FB1.5 hat die FB1.5 SP: 8 ms execute, 3000 ms fetch Query: 800 ms execute, 3000 ms fetch FB2.0 SP: etwa wie FB1.5 Query: 8000 ms execute, 10000 ms fetch Heiko |
Re: Performance-Prob mit Subselect
Und wenn du die 4 tabelle auch dazujoinst?
|
Re: Performance-Prob mit Subselect
|
Re: Performance-Prob mit Subselect
Hallo mkinzler,
welche 4. Tabelle ? Das ist ja ein Subselect mit NOT IN. OK, man könnte ein outer join mit "IS NULL" machen. wie DeddyH aus genau hingelinkt hat ... ;) mal sehen Heiko |
Re: Performance-Prob mit Subselect
SQL-Code:
So gehts ohne subselect, vielleicht ist es schneller. Eigentlich sollte das ja in Nullkommanix gehen....
Select Booking.booking_id,
Booking.project_id From ( Booking Join Project On Project.project_id=Booking.project_id Join Pos On Pos.project_id=Project.project_id ) Left join except_projects on except_projects.project_id = Booking.projectID where except_projects.project_id is null Ach ja: Ich weiss, das Du was gegen Left Joins hast, aber man weiss nie, was ein Optimizer draus macht. |
Re: Performance-Prob mit Subselect
Hallo,
die Query von alzaimar bringt es fast.
SQL-Code:
OK das Booking.position_id hatte ich unterschlagen.
Select Booking.booking_id,
Booking.project_id From ( Booking Join Project On Project.project_id=Booking.project_id Join Pos On Pos.position_id=Booking.position_id ) Left join except_projects on except_projects.project_id = Booking.projectID where except_projects.project_id is null Ausführungszeit unter FB1.5 und FB2.0 ist OK, 1600 ms execution, 3000 ms fetch Tja, mit einer SP bin ich bei 9 ms execution. Soll ich nu ne SP nehmen oder besser das "Standard"-SQL lassen. Was meint ihr ? Heiko |
Re: Performance-Prob mit Subselect
Wenn die SP schon existiert, warum nicht nehmen?
|
Re: Performance-Prob mit Subselect
Hallo,
die habe ja nur mal so schnell "getippert". Das Problem ist, wenn ich mal ne andere DB unterstützen will, muss ich wieder eine SP anpassen. Heiko |
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:01 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz