SQL optimimieren notwendig Max()

[Dumpfbacke]

Hallo Ihr Experten,
ich haben da mal eine Frage ob man hier bei einen SQL Befehlt noch etwas optimieren kann. Ich möchte das größte Datum aus einer Tabelle haben bei der gewisse Bedingungen erfüllt sind.

Delphi-Quellcode:

Select Max(Feld1) From tabelle1 where Feld2 = 'Schraube' and Feld3 <> 'klein' and Feld 3 <> ''

Auf allen Feldern (Feld 1 - 3) liegt hier ein kombi Index drauf. Das zeites habe ich auhc nich einen als Absteigend angelegt.

Das ganze dauter 6 Sekunden wenn ich nun das Max(Feld1) für ein * ersetze kommt als Ergebis hier 3 zelen raus.

Das schöne ist as es jetzt lt. IBExpert nur 16ms dauert.

Ich benötige aber das größe Datum von diesen drei Datensätzen. Habe ich das was falsch gemacht oder kann man da was optimieren.

Ach so das ganze dauer so lange bei mit also 16ms da in der Tabelle 58 Mio Datensätze vorhanden sind und es ein gang ganz alter Server ist mit noch richtigen Platten und keinen SSD. Ich nur zum entwicken gedacht und dazu genügt die Kiste noch.

Danke Dumpfbacke

[Uwe Raabe]

Diese Einschränkung ist redundant bzw. offenbar nicht so gemeint:

Delphi-Quellcode:

and Feld3 = 'klein' and Feld3 <> ''

Wenn

Delphi-Quellcode:

Feld3 = 'klein'

, dann ist natürlich immer auch

Delphi-Quellcode:

Feld3 <> ''

.

[himitsu]

Zu Feld2 und Feld3 gibt es auch passende Indize?

[Dumpfbacke]

Zitat:

Zitat von Uwe Raabe (Beitrag 1500702)

Diese Einschränkung ist redundant bzw. offenbar nicht so gemeint:

Delphi-Quellcode:

and Feld3 = 'klein' and Feld3 <> ''

Wenn

Delphi-Quellcode:

Feld3 = 'klein'

, dann ist natürlich immer auch

Delphi-Quellcode:

Feld3 <> ''

.

Doch das ist so gewollt bzw. die Vorgabe. Die Felder sind nicht NULL sondern teilweise leer und diese sollen hier nicht berücksichtig werden.

[Dumpfbacke]

Zitat:

Zitat von himitsu (Beitrag 1500705)

Zu Feld2 und Feld3 gibt es auch passende Indize?

Ja es isgt ein Index über alle Leder hier. Wenn ich die einzelenn Zeilen mir hohe geht es ja auch super fix nur bei Max dauert es leider "so lange".

[Frickler]

Zitat:

Zitat von himitsu (Beitrag 1500705)

Zu Feld2 und Feld3 gibt es auch passende Indize?

Sie schreibt von "Kombi-Index", d.h. es gibt einen Index "feld1;feld2;feld3". Davon wird m.W. bei Firebird abgeraten. Besser 3 einzelne Indexe. Kombi-Index, das hat man mal gebraucht bei Paradox.

P.S.: was ist mit einer geschachtelten Abfrage a la

Code:

SELECT MAX(x.Feld1) FROM (SELECT Feld1 FROM ...) x

[Delphi.Narium]

Hab' ich das recht verstanden? Du suchst

SQL-Code:

Select datum From tabelle1 where Feld2 = 'Schraube' and Feld3 = 'klein' and Feld 3 <> ''

und davon dann den Satz mit dem höchsten Datum?

SQL-Code:

select max(Datum) as Max_Datum from (
  select datum 
  from tabelle1 
  where Feld2 = 'Schraube' and Feld3 = 'klein' and Feld 3 <> ''
)

Damit werden erstmal "nur" die Sätze gesucht, die per Index und Bedingung wohl recht schnell gefunden werden.

Von der nun recht kleinen "Restmenge" suchen wir anschließend das höchste Datum.

Das kann, aus Erfahrung, je nach Konstellation schonmal so die eine oder andere Minute an Abfragezeit einsparen.

Dann hast Du einen Index auf Feld1, Feld2 und Feld3. Feld1 ist aber nicht in der Wherebedingung enthalten und hat hier, als erstes Feld im Index (eventuell) keine Auswirkung bzw. der Index wird nicht oder nicht optimal genutzt.

Was sagt denn der Ausführungsplan zu der Abfrage?

Probiere es bitte mal mit dem geschachtelten SQL und einem Index nur auf Feld2 und Feld3.

Zu Uwes Anmerkung bezüglich der Wherebedingung und Deiner Antwort:

Zitat:

Doch das ist so gewollt bzw. die Vorgabe. Die Felder sind nicht NULL sondern teilweise leer und diese sollen hier nicht berücksichtig werden.

Wenn Feld3 = 'klein' ist, gilt zwangsläufig: Feld3 <> ' '.
Wenn diese reduntante Prüfung laut Vorgabe gewollt ist, sollte man mal die Sinnhaftigkeit der Vorgabe überprüfen.

Vorteil: Die Datenbank spart sich damit eine unnütze Abfrage, was sich in Bezug auf die Laufzeit (ggfls. sogar die Nutzung des Index) durchaus positiv auswirken kann.

[Dumpfbacke]

Leider habe ich hier einen kleinen Tipfehler gemacht es muss richtig lauten Feld3 <> 'klein'. Aus diesem grund auch <> ''. Sorry. Ich habe es oben mal angepasst.

[Dumpfbacke]

[QUOTE=Delphi.Narium;1500711]Hab' ich das recht verstanden? Du suchst

und davon dann den Satz mit dem höchsten Datum?

SQL-Code:

select max(Datum) as Max_Datum from (
  select datum 
  from tabelle1 
  where Feld2 = 'Schraube' and Feld3 = 'klein' and Feld 3 <> ''
)

Das dauert genau so lange wie meiner

[IBExpert]

es gäbe diverse weg wie man das optimieren kann, einzelindizes machen dem firebird server meistens das leben
einfacher, bei 68 mio records kann es aber auch mal ein kombinierter sein.

was versuchst du damit
and Feld3 = 'klein' and Feld 3 <> ''

wenn feld3 'klein' ist, dann kann es nicht '' sein

vorschlag

Indexreihefolge und anderes sql (sollte mit kombiniertem index "feld2, feld3, feld1 desc" nur in der Reihenfolge
ganz gut laufen, aber auch mit einzelindizes

Select first 1 Feld1 From tabelle1 where Feld2 = 'Schraube' and Feld3 = 'klein' order by feld1 desc

vorteil liegt darin, das der index nur bis zur einspungadresse gebraucht wird, keine gesamtauswertung machen muss
Sollte mit dem index wie aufgezeigt in richtiger reihenfolge oder einzelindizes auch gut laufen

Grund: wenn dein index mit feld1 losgeht aber das gar nicht für where gebraucht wird, ist der nahezu nutzlos
das ist auch der Grund warum einzelindizes oft besser sind, weil da der optimierer selber erkennen kann,
das zB in feld2 nur 1000 unterschiedliche werte sind und und feld3 zB 10000, das ist die sogenannte Selektivität.
wenn aber in feld1 zB ein timestamp ist, das kann es sein, das da drin 68 mio unterschiedliche werte sind

der kombindex der damit beginnt, ist völlig unbrauchbar

es wäre sicherlich hilfreich, reale metadaten zu posten und nicht immer nur handgeklöppelte sql beispiele
ebenso wie index strukturen und die echten sqls (auf der seite ddl in ibexpert findet man immer
alles auf einen blick und das ist auch selten Raketenwissenschaft, was man damit veröffentlicht,
außerdem sind wir alle hier ja unter uns 8-))

[Dumpfbacke]

Danke für den Hinweis Holger.

Ich verstehe das ich es in Zukunft genauer beschrieben muss. Das mit dem Kopieren ist auch einfacher. Bei mir heißen die Felder hier noch Feld1 usw., da es nur der erste Test ist und ich die Daten mal so erhalten haben. Nicht schön aber selten.

Also das mit dem Feld 3 war ein Kopierfehler das habe ich zum testen mal geändert und dann genau kopiert für hier. Es muss beides mal mal <> sein. Ich habe es im ersten Post noch schnell geändert.

Nun zum Thema Index. Es liegt auf jedem Feld ein einzel Index also auf Feld1, Feld2 und Feld3. Wobei auf Feld1 auch noch ein DESCENDING Index liegt wegen dem Max. Auch der Kompi Index ist so angelegt, wie du geschrieben hast. Das habe ich anscheined unwissend schon richtig gemacht. :-D man bin ich gut da mach ich mal was richtig und weiß es noch nicht einmal :oops:

Es wird hier der Kombi Index benutzt sowohl bei Deinen Select mit First als auch bei meinen mit max. Beides ist identisch und dauert 6 Sekunden.

Was mich hier halt so wundert ist das wenn ich mir die Daten komplett anzeigen lasse also alle 3 Zeilen das es ruck zuck da ist. Nur bei dem Max oder First dauert es so lange.

Was mir noch aufgefallen ist das wenn ist nicht den größten Wert sonden den kleinsten Wert haben möchte, so geht das auch Ruck Zuck, Also bei meinem an Stelle von max uf min änder oder bei Deinem des DESC weglasse.


Der Index wurde angelagt mit. CREATE DESCENDING INDEX TABELLE_ABSTEIGEND ON TABELLE1 (FELD2, FELD3, FELD1);


Feld 1 ist ein Datumsfeld und Feld2 und Feld 3 ein Varchar.

Falles es hier hilft mal die Daten


bei Max Wert

------ Performance info ------
Prepare time = 15ms
Execute time = 6s 579ms
Avg fetch time = 6.579,00 ms
Current memory = 90.467.880
Max memory = 228.991.144
Memory buffers = 1.024
Reads from disk to cache = 90.198
Writes from cache to disk = 0
Fetches from cache = 90.276


Bei min wert oder bein anzeigen der drei Zeilen

------ Performance info ------
Prepare time = 0ms
Execute time = 515ms
Avg fetch time = 515,00 ms
Current memory = 90.467.424
Max memory = 228.991.144
Memory buffers = 1.024
Reads from disk to cache = 6.878
Writes from cache to disk = 0
Fetches from cache = 6.883

Wenn Du noch was benötigst sag einfach bescheid den ch verstehe das ganze eh nicht mehr.

Dane

[IBExpert]

<> ungleich : hat keinerlei Hilfe durch den index, frei nach dem motto suche alle
einträge im deutschen Telefonbuch die nicht 'Meier' heissen ....

der kombinierte index wird dadurch nur unnötig groß


wenn in feld3 eh alles ungleich ist, lass den kombinierten
index am besten ganz weg und mach je einen auf feld1 (desc) und einen auf feld2 (asc)

außerdem würde ich mal zumindest auf so einer lahmen kiste die cache buffers hochsetzen, 1024 ist sehr wenig
(services-database properties in ibexpert)


also tip zusammengefasst: kombinierten index komplett löschen, einzelindizes erst mal nur auf feld1 und feld2

[himitsu]

Zitat:

Zitat von Frickler (Beitrag 1500710)

Sie schreibt von "Kombi-Index", d.h. es gibt einen Index "feld1;feld2;feld3"

Dieser Index sollte dann ja nur verwendet werden, wenn feld1, feld2 und feld3 im WHERE stehen.
Hier würde ich nicht davon ausgehn, dass dieser Index verwendet wird, und es auf einen FullTableScan hinaus läuft.

Für IB wird doch auch irgendwie an einen QueryPlan kommen können (EXPLAIN ANALYSE oder so),
um so zu sehn, was genommen wird?

[Dumpfbacke]

Ja Index wird benutzt das ist da das was mich hier so wurder.

Zitat:

Zitat von Frickler (Beitrag 1500710)

Sie schreibt von "Kombi-Index", d.h. es gibt

Für IB wird doch auch irgendwie an einen QueryPlan kommen können (EXPLAIN ANALYSE oder so),
um so zu sehn, was genommen wird?

[jobo]

Klingt für mich so, dass max for der Filterung ausgeführt wird, statt danach.
Ich würde es mit Schachtelung der Abfragen versuchen, als „Denk-Hilfe“ für den Ausführungsplan.
(Ich weiß nicht, ob und wie gut FB Abfragen optimiert, also halt ein „Selbstoptimierungsversuch“)

Select max(feld1) from
(select feld1,feld2,feld3 frommytable
where …
) x

Idee wäre also: Die Abfrage in Klammern liefert erfreulich schnell 3 Datensätze und wird außen dann mit MAX leicht fertig. Vielleicht gibt es auch brutalere Umschreibungen des SQL, um FB dazu zu zwingen so vorzugehen. Vielleicht ist es auch gar nicht nötig, wenn man es wirklich richtig macht.

[Dumpfbacke]

Zitat:

Zitat von IBExpert (Beitrag 1500722)

also tip zusammengefasst: kombinierten index komplett löschen, einzelindizes erst mal nur auf feld1 und feld2

Habe ich gemacht und die Memory buffers mal verdoppelt. Es blebt dei den 6 Sekunden. Die Kiste mag es einfachnicht machen.

------ Performance info ------
Prepare time = 0ms
Execute time = 6s 781ms
Avg fetch time = 6.781,00 ms
Current memory = 18.142.400
Max memory = 18.181.024
Memory buffers = 2.048
Reads from disk to cache = 90.240
Writes from cache to disk = 0
Fetches from cache = 90.319

[Dumpfbacke]

Zitat:

Zitat von jobo (Beitrag 1500730)

Klingt für mich so, dass max for der Filterung ausgeführt wird, statt danach.
Ich würde es mit Schachtelung der Abfragen versuchen, als „Denk-Hilfe“ für den Ausführungsplan.
(Ich weiß nicht, ob und wie gut FB Abfragen optimiert, also halt ein „Selbstoptimierungsversuch“)

Select max(feld1) from
(select feld1,feld2,feld3 frommytable
where …
) x

Idee wäre also: Die Abfrage in Klammern liefert erfreulich schnell 3 Datensätze und wird außen dann mit MAX leicht fertig. Vielleicht gibt es auch brutalere Umschreibungen des SQL, um FB dazu zu zwingen so vorzugehen. Vielleicht ist es auch gar nicht nötig, wenn man es wirklich richtig macht.

Nein geht leider auch nicht. Es bleibt wiw bei jeder anderen Version bei den 6 Sekunden. Das ganze ist ein wenige merkwürdig.

[Blup]

Meiner Meinung nach müsste dieser Index für diese Abfrage optimal sein:

SQL-Code:

CREATE DESCENDING INDEX TABELLE1_IDX ON TABELLE1 (FELD2, FELD1);
/* */

- alle Einträge für Feld2 = "Schraube" können direkt über den Index angesprochen werden
- innerhalb dieses Bereichs stehen die grössten Werte für Feld2 am Anfang
- die Abfrage muss nur durch den Bereich gehen, bis die Bedingung für Feld3 erfüllt ist

Wenn jedes Feld einen einzelnen Index bekommt, dann Feld1 mit absteigender Reihenfolge.

[IBExpert]

wenn du die ibexpert vollversion hast gibt die seite performance analyse noch einiges an detailinfos
zu deinem sql, ich vermute mal das der auf irgendeinem teil deiner abfrage viel zu lange und viel zu viel
einträge abklappert.

wenn das mit meinem first 1 .... order by gemacht wird und einzelindizes existieren sollte es
deutlich schneller sein als 6 sekunde, es sei denn, dein feld2 ist in 100% der datensätze

mach doch sonst mal erste select count(*) from tab where feld2=xxx
um da zu sehen ob der index überhaupt eine sinnvolle einschärkung macht

[Dumpfbacke]

Zitat:

Zitat von IBExpert (Beitrag 1500739)

mach doch sonst mal erste select count(*) from tab where feld2=xxx
um da zu sehen ob der index überhaupt eine sinnvolle einschärkung macht

Ergbisnis ist 29 Stück und es dauerte 31 ms fürs Ergebnis.

[Jumpy]

Was bedeutet es denn, dass die Reads from disk to cache bei der Max Abfrage so hoch sind, bei der Min aber nicht?

[Blup]

Dein Index über das Feld1 ist aufsteigend.
Das heist bei einer min()-Abfrage findet die DB das richtige Ergebnis gleich am Anfang, bei der max()-Abfrage muss die DB bis zum Ende durchsuchen.
Dafür kann man dann einen absteigenden Index anlegen.
Für manche Anwendungsfälle sind auch zwei Index über ein Feld sinnvoll, einer aufsteigend und einer absteigend.

[IBExpert]

probier mal

Code:

select first 1 feld1,feld2,feld3
from
(select feld1, feld2,feld3 from tab where feld2=xxx)
where feld2 not in ('klein','')
order by feld1 desc

ich bin mir ziemlich sicher das da noch indizes benutzt werden, die man nicht benutzen sollte
und bei dem o.a. verfahren kann ein index nur in der inneren Abfrage benutzt werden , das
außenrum nutzt niemals indizes.

[Dumpfbacke]

Zitat:

Zitat von Blup (Beitrag 1500787)

Dein Index über das Feld1 ist aufsteigend.
Das heist bei einer min()-Abfrage findet die DB das richtige Ergebnis gleich am Anfang, bei der max()-Abfrage muss die DB bis zum Ende durchsuchen.
Dafür kann man dann einen absteigenden Index anlegen.
Für manche Anwendungsfälle sind auch zwei Index über ein Feld sinnvoll, einer aufsteigend und einer absteigend.

Das Feld also Feld1 hat zwei einen Auf und einer Absteigend.

[Dumpfbacke]

Zitat:

Zitat von IBExpert (Beitrag 1500789)

probier mal

Code:

select first 1 feld1,feld2,feld3
from
(select feld1, feld2,feld3 from tab where feld2=xxx)
where feld2 not in ('klein','')
order by feld1 desc

ich bin mir ziemlich sicher das da noch indizes benutzt werden, die man nicht benutzen sollte
und bei dem o.a. verfahren kann ein index nur in der inneren Abfrage benutzt werden , das
außenrum nutzt niemals indizes.

Ich habe es versucht. Es wird hier der Index von Feld2 benutzt und es dauert 6 Sekunden bis zum Ergebnis.

------ Performance info ------
Prepare time = 0ms
Execute time = 6s 718ms
Avg fetch time = 6.718,00 ms
Current memory = 18.151.488
Max memory = 18.236.568
Memory buffers = 2.048
Reads from disk to cache = 90.240
Writes from cache to disk = 0
Fetches from cache = 90.319

Das ganze ist schon etwas merkwürdig.

[Blup]

Du hast deine Bedingung für die Abfrage geändert.
Die zweite Bedingung der ursprünglichen Abfrage bezog sich auf Feld3.
("not in" oder mehrere "<>" führen zum selben Plan und sind somit auch gleich langsam)

SQL-Code:

/**/
Select Max(Feld1) From tabelle1 where Feld2 = 'Schraube' and Feld3 <> 'klein' and Feld 3 <> ''

Darauf bezogen sind auch die Optimierungsversuche und mein Vorschlag für einen Index über zwei Felder (den du als Plan für diese Abfrage direkt angeben könntest).

Deine neue Abfrage macht nicht viel Sinn, da sich die äußere Bedingung auch auf Feld2 bezieht.
Mit der Idee zweier geschachtelten Abfragen wurde versucht den SQL-Server auszutricksen und ein bestimmten Plan für die Abfrage zu erzwingen.
Das klappt aber scheinbar nicht, weil der die Abfrage vor der Ausführung optimiert und wieder umstellt.
Es ist auch sinnvoller den Ausführungsplan direkt anzugeben, als zu solchen Tricks zu greifen.
Andernfalls muss man sich den automatisch erzeugten Plan genau anschauen.
Gerade wenn mehere Index für ein Feld existieren, muss auch der Richtige und in der richtigen Reihenfolge genutzt werden.

[hoika]

Hallo,
ich würde mal ein Backup/Restore machen.

[Jasocul]

Folgender Vorschlag:

Code:

Select Max(Feld1)
from (select Feld1, Feld3
      from (Select Feld1, Feld2, Feld3
            from tabelle1
            where Feld2 = 'Schraube')
      where Feld3 <> 'klein' and Feld 3 <> '')

Das sollte dazu führen, dass im tiefsten Sub-Select der Index von Feld2 gezogen wird.
Dieser liefert nur 29 Datensätze.
Das Sub-Select in der darüber liegenden Ebene macht ein Full Table Scan über die 29 Datensätze. Dies darf nur ein paar ms dauern.
Selbst wenn dann immer noch 29 Datensätze übrig wären, kann das Max(Feld1) auf oberster Ebene ebenfalls nur ms dauern.

Sollte die gesamte Abfrage immer noch 6 Sekunden benötigen, ist entweder der Index für Feld2 nicht in Ordnung oder es liegt mMn nach eher ein technisches oder DB-Konfigurations Problem vor.

[Delphi.Narium]

Eventuell mal die Statistiken neu erstellen.

Und dann möchte ich bitte mal die Texte aus

SQL-Code:

select mon$sql_text, mon$explained_plan from MON$STATEMENTS
where mon$sql_Text like '%namedeinertabelle%'

sehen.

Das könnte dann z. B. so in der Art aussehen:

SQL-Code:

select max(id) from beipackzettel where kennungsart = 'Schraube' and kennung <> 'klein' and kennung <> ' '

SQL-Code:

Select Expression
    -> Aggregate
        -> Filter
            -> Table "BEIPACKZETTEL" Access By ID
                -> Bitmap
                    -> Index "IX_BEIPACKZETTEL_KENNUNGSART" Range Scan (full match)

Obwohl es hier einen Index für die Spalte "kennung" gibt, wird er nicht genutzt, ebensowenig wie der Index auf "id".

Eventuell den Inhalt von mon$explained_plan der unterschiedlichen Statements miteinander vergleichen. Führen sie überhaupt zu unterschiedlichen Ausführungsplänen?

[Dumpfbacke]

Zitat:

Zitat von Delphi.Narium (Beitrag 1500819)

Eventuell mal die Statistiken neu erstellen.

Und dann möchte ich bitte mal die Texte aus

SQL-Code:

select mon$sql_text, mon$explained_plan from MON$STATEMENTS
where mon$sql_Text like '%namedeinertabelle%'

sehen.

Das könnte dann z. B. so in der Art aussehen:

SQL-Code:

select max(id) from beipackzettel where kennungsart = 'Schraube' and kennung <> 'klein' and kennung <> ' '

SQL-Code:

Select Expression
    -> Aggregate
        -> Filter
            -> Table "BEIPACKZETTEL" Access By ID
                -> Bitmap
                    -> Index "IX_BEIPACKZETTEL_KENNUNGSART" Range Scan (full match)

Obwohl es hier einen Index für die Spalte "kennung" gibt, wird er nicht genutzt, ebensowenig wie der Index auf "id".

Eventuell den Inhalt von mon$explained_plan der unterschiedlichen Statements miteinander vergleichen. Führen sie überhaupt zu unterschiedlichen Ausführungsplänen?

Das funktioniert leider bei mir nicht. Ich bekomme diese Fehlermeldung.

SQL error code = -206.
Column unknown.
MON$EXPLAINED_PLAN.
At line 1, column 41.
Dynamic SQL Error.

[Dumpfbacke]

Zitat:

Zitat von Jasocul (Beitrag 1500812)

Folgender Vorschlag:

Code:

Select Max(Feld1)
from (select Feld1, Feld3
      from (Select Feld1, Feld2, Feld3
            from tabelle1
            where Feld2 = 'Schraube')
      where Feld3 <> 'klein' and Feld 3 <> '')

Das sollte dazu führen, dass im tiefsten Sub-Select der Index von Feld2 gezogen wird.
Dieser liefert nur 29 Datensätze.
Das Sub-Select in der darüber liegenden Ebene macht ein Full Table Scan über die 29 Datensätze. Dies darf nur ein paar ms dauern.
Selbst wenn dann immer noch 29 Datensätze übrig wären, kann das Max(Feld1) auf oberster Ebene ebenfalls nur ms dauern.

Sollte die gesamte Abfrage immer noch 6 Sekunden benötigen, ist entweder der Index für Feld2 nicht in Ordnung oder es liegt mMn nach eher ein technisches oder DB-Konfigurations Problem vor.

Es ist wie verhext hier. Es geht auch nicht. Bei mir muss doch dann irgendetwas nicht in Ordnung sei. Es kommt erneut zu den 6 Sekunden. Das ganze wundert micht so langsamm.

Prepare time = 0ms
Execute time = 6s 657ms
Avg fetch time = 6.657,00 ms
Current memory = 18.323.720
Max memory = 147.452.584
Memory buffers = 2.048
Reads from disk to cache = 90.199
Writes from cache to disk = 0
Fetches from cache = 90.277

[himitsu]

In einem "normalen" Index steht drin , was es zu wechem Datensatz gibt.
Du suchst aber nach "nicht da".
> ich suche ABC und bekomme als Ergebnis alle Datensatzzeiger direkt aus dem einen Index-Eintrag
> im Index steht aber keine Liste aller nichtzutreffenden Datensätze

Klar könnte man denken, dass man nun einfach danach sucht und wenn mein Datensatz nicht im Ergebnis vorkommt, dann nehme ich den, aber dafür muß man ja dennoch erstmal alles durchsuchen ... da denkt sich die Datenbbank wohl: Wenn ich sowieso alles laden muß, dann ignoriere ich einfach den Index.

In vielen DBMS gibt es verschiedene Arten von Indize.
Eventuell funktioniert es mit einer anderen Art besser?

Oder einfach selber Mal versuchen umzudrehen und der DB ein "suche nach" unterjubeln?
Also in einem JOIN/SubSELECT nach

SQL-Code:

WHERE kennung IN ('klein', ' ')

suchen und dann via

SQL-Code:

IS NOT NULL

oder

SQL-Code:

NOT Exists(...)

mit dem eigentlichen SELECT verknubbeln.

[Jasocul]

Dann mal ein anderer Ansatz (Abfrage ist ungeprüft eingetippt):

Code:

with q1 as 
     (Select Feld1, Feld2, Feld3
      from tabelle1
      where Feld2 = 'Schraube'),

     q2 as
     (select Feld1, Feld3
      from q1
      where Feld3 <> 'klein' and Feld 3 <> '')

Select Max(Feld1)
from q2

Damit sollte die DB keine Möglichkeit mehr haben, den Index der ersten Abfrage zu umgehen. Der Rest ist dann aber ein Full-Table-Scan auf das Ergebnis der ersten Abfrage. Bei 29 Datensätzen sollte das aber kein Problem sein.
Du kannst natürlich mal die erste Abfrage separat ausführen, ob die auch wirklich schnell ist. Wenn die schon ein paar Sekunden braucht, liegt das Problem woanders.

[Frickler]

Was ist, wenn Du einen zusätzlichen berechneten Index anlegst:

Code:

CREATE INDEX feld3nichtleer ON Tabelle1 COMPUTED BY (Feld3<>'')