Firebird IN, EXISTS Langsam

[Gruber_Hans_12345]

Zitat von jobo:

@mkinzler
Die Beschreibung klingt gut
Für einen einzelnen Datensatz ist es ja sicherlich auch richtig.
Aber was macht der Optimizer, wenn das not exists gegen tausende oder mehr Artikel gefahren wird? Immer wieder los rennen und suchen .. ?

Also von denzeiten her, würde ich sagen, ja er macht das - leider - das ist ja das problem hier

Zitat von jobo:

@Gruber_Hans_12345
1500 -2000 Datensätze sind nicht viel.
Wenn das V_AUFTRAG_PO im echten Leben so komplex ist, lohnt es sich vielleicht, erst die Differenz zu bilden (die mglw. noch zu viele Datensätze enthält) und anschließend auf dem Ergebnis die "komplexen " Joins zu fahren.

Also ungefähr

Code:

select * from (
  SELECT A.ID
  FROM ARTIKEL A
  LEFT JOIN POSITION T ON (A.ID = T.ARTIKEL_ID)
  WHERE T.ARTIKEL_ID IS NULL
  GROUP BY A.ID
  ) Dif
where .. komplexe Bedingungen

Hier gibts vielleicht noch tolle Hinweise zum Optimizer.

Also das mit dem group habe ich auch schon probiert, das hat leider auch gar nichts gebracht, entweder hilft dann hier der index soviel, das es nicht mehr soviel unterschied macht,
Hätte es auch schon als STORED PRCOEDURE probiert, aber noch gescheitert

Als reines Script im Client abgelegt, zuerst alle ARTIKEL IDs laden, dann die Liste mit den verwendeten laden, davon per Delphi ein DIFF machen, und dann noch mal ein SELECT -> ist um welten schneller, aber leider zu komples, für viele sachen

[jobo]

Ich glaub, Du hast mich falsch verstanden. Es ging mir nicht ums Group, das innere Statement ist ja nur eine Kopie des von mir favorisierten Statement von TBx. Ich hab lediglich das "V_AUFTRAG_PO" gegen "POSITION" getauscht, um zu verdeutlichen, dass Du den komplexen View erstmal beiseite lässt.

Hast Du Dir mal den Optimizer Link angeschaut?

[Gruber_Hans_12345]

Zitat von jobo:

Ich glaub, Du hast mich falsch verstanden. Es ging mir nicht ums Group, das innere Statement ist ja nur eine Kopie des von mir favorisierten Statement von TBx. Ich hab lediglich das "V_AUFTRAG_PO" gegen "POSITION" getauscht, um zu verdeutlichen, dass Du den komplexen View erstmal beiseite lässt.

Hast Du Dir mal den Optimizer Link angeschaut?

JA, das problem ist die komplexe Abfrage mit 3 Tabellen per Joins ist in der inneren SQL - Also dort wo geschaut wird, ob diese Artikel in der Positions Tabelle verhanden sind (Verlinkt mit Auftrag Tabelle und einer Auftrags informations Tabelle) deshalb ist es da problematisch ...

... habs zwar gelesen, aber hab mir nicht wirklich was raussuchen können, was mir helfen könnte in diesem fall


Ich habe einfach das problem, das so eine "primitive" sache, wo es eigentlich nur darum geht eine SELECT zu machen (die 0.05 sekunden dauert) und von dieser dann ID's aus einer anderen Abfrage abzuziehen (die auch 0.05 sekunden dauert) - das dann 26 sekunden dauert ... das geht enfach nicht in meinen kopf, das man das nicht mit "normalen einfachen" SQL Mitteln zumindest auf 0.5 Sekudnen oder so optimieren kann
Und das müsste ja eigentlich auch OHNE einen Index auf Artikel_ID funktionieren ... (Schon klar ich werde morgen den Index drauf legen ... aber ist mir noch immer nicht ganz logisch, das es nicht ohne den geht ... )

[omata]

Deine DB-Struktur sieht also folgendermaßen aus...

SQL-Code:

CREATE TABLE artikel (
  artikel_id int,
  CONSTRAINT PK_artikel 
    PRIMARY KEY (artikel_id)
);

CREATE TABLE position (
  position_id int,  
  CONSTRAINT PK_position 
    PRIMARY KEY (position_id)
);

CREATE TABLE artikel_position (
  artikel_id int,
  position_id int,  
  CONSTRAINT PK_artikel_position 
    PRIMARY KEY (artikel_id, position_id),
  CONSTRAINT FK_artikel_position_artikel 
    FOREIGN KEY (artikel_id) REFERENCES artikel (artikel_id),
  CONSTRAINT FK_artikel_position_position 
    FOREIGN KEY (position_id) REFERENCES position (position_id)
);

Ist das richtig?

[Gruber_Hans_12345]

Also das ist die original Abfrage

Code:

SELECT A.ARTIKELNUMMER 
FROM ARTIKEL A
/*Hier wäre noch joins drinnen, aber die habe ich mal weggelassen, da diese keine zeit in anspruch nehmen */
WHERE A.ID NOT IN
(
SELECT T.ARTIKEL_ID
FROM AUFTRAG VA, AUFTRAG_INFO AF, POSITIONEN T
WHERE (AF.ID = VA.INFO_ID) AND (T.AUFTRAG_ID = VA.ID) AND (VA.MesseSTATUS > 0)
AND ((CAST(AF.MesseBis AS Date) >= CURRENT_TIMESTAMP) And (Cast(AF.MesseVon AS Date) <= CURRENT_TIMESTAMP + 10))
)

[EDIT}Also das erzeugen eines Index auf POSITIONEN(ARTIKEL_ID) hat es gebracht ... nun dauerrts ca 0.05 sekunden ... ich verstehe zwar nicht warum er das braucht aber, vielleicht merke ich es mir nun .... [/EDIT]

[omata]

Schade, das du keine Fragen beantwortest. Naja, dein Problem ist ja gelöst, verstehen wird auch überbewertet.

[Gruber_Hans_12345]

Zitat von omata:

Schade, das du keine Fragen beantwortest. Naja, dein Problem ist ja gelöst, verstehen wird auch überbewertet.

Also dachte mit meiner original Abfarge wäre es so halbwegs geklärt wie die DB aussieht ....

so versuche es noch einmal :

Code:

CREATE TABLE ARTIKEL (
  ID INTEGER NOT NULL
, ARTIKELNUMMER VARCHAR(100)
, PRIMARY KEY("ID"));

CREATE TABLE AUFTRAG (
  ID INTEGER NOT NULL
, MesseBis TIMESTAMP
, MesseVon TIMESTMAP
, PRIMARY KEY("ID"));

CREAT TABLE AUFTRAG_INFO  (
  ID INTEGER NOT NULL
, INFO_ID INTEGER
, MESSESTATUS INTEGER
, PRIMARY KEY("ID"));

CREATE TABLE POSITIONEN  (
  ID INTEGER NOT NULL
, AUFTRAG_ID INTEGER
, ARTIKEL_ID INTEGER
, PRIMARY KEY("ID"));

[sx2008]

Wenn wir mal folgende Abfrage anschauen:
SELECT A.ID FROM ARTIKEL A WHERE NOT EXISTS (SELECT * FROM V_AUFTRAG_PO T WHERE T.ARTIKEL_ID = A.ID)
dann kann diese Abfrage "rasend schnell" ablaufen, wenn auf dem Feld V_AUFTRAG_PO.ARTIKEL_ID ein Index existiert.
Die SQL-Engine sollte in diesem Fall nur den Index der Tabelle V_AUFTRAG_PO befragen ob ein bestimmter Schlüssel vorhanden ist oder nicht.
Die Unterabfrage SELECT * FROM V_AUFTRAG_PO wird dabei im Grunde genommen überhaupt nicht ausgeführt.
Dafür ist es natürlich erforderlich, dass Firebird so schlau ist nur den Index abzurufen und Zugriffe auf die Tabelle V_AUFTRAG_PO zu unterlassen.
Manchmal (je nach DBMS) erkennt die Engine diese Abkürzung nur wenn in der Unterabfrage SELECT * FROM ... steht.
Im Prinzip kann man in der Unterabfrage auch SELECT V_AUFTRAG_PO.ARTIKEL_ID FROM V_AUFTRAG_PO schreiben; das Ergebnis ist theoretisch gleichwertig zu SELECT * FROM V_AUFTRAG_PO.

Irgendwie stösst SQL hier an seine Grenzen, weil man in der Unterabfrage eine Feldliste angeben muss, die doch im Zusammenhang mit EXISTS nie benützt wird.