DEBUG - Abgesetzten SQL herausfinden

[BenderD]

... der Index Mandant, Kundennummer, Rechnungsdatum erlaubt einen Index only access für den Subselect in der in Klausel (und kann auch eine Abschätzung für die Selektivität liefern).

D*B

[Fuerchau]

OK, das könnte ein Argument sein, wobei ich wieder Mandant/Rechnungsdatum/Kundennr vorziehen würde. Allein dadurch würde ich schon ca. 2,8 Mio. Keys weniger benötigen.
Mal sehen, vielleicht probiere ich das mal aus.

[BenderD]

... die where in (subselect) Abfragen haben häufig eine Tendenz zum full table scan und in diesem Fall bezieht sich der wirksame Selektor auch noch auf die größere Tabelle. Solche Abfragen sind anfällig für Wechsel in der Zugriffsstrategie. Wenn man selber Zusatzinformationen über die Selektivität hat, kann man eventuell versuchen über eine Order by clause eine Entscheidung nahezulegen. Oder die mehrstufige Variante, die immer schnell ist (in diesem Fall könnte man den subselect in eine UDT packen, das funzt dann,bis die UDTs ordentlich implementiert sind...)

Dieter

[AG1965_2]

Witzig, die Maschine sammelt Infos wie die NSA, kann aber scheinbar genau so selten sinnvolle Schlüsse daraus ziehen. :-)

[Fuerchau]

Häufig kann man die "in select(..)"/"not in (select..)" durch eine Exists-Klausel beschleunigen, da hier häufig nur ein Zugriff erfolgt.
Die Exists-Klausel wurde meines Wissens nach erst mit V4R5 eingeführt.
Leider habe ich noch genau einen AS/400-Kunden mit V4R3 (man glaubt es kaum).
Hier existiert der Exists nicht (schönes Wortspiel).

[KingofKning]

Witzig, die Maschine sammelt Infos wie die NSA, kann aber scheinbar genau so selten sinnvolle Schlüsse daraus ziehen. :-)

Der Spruch ist gut.....

GG