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
)