Index bei StoredProcezure

[Delphi.Narium]

Wenn mich nicht alles täuscht, machst Du folgendes:

In der Prozedur holst Du alle 86 Mio Datensätze ohne Einschränkung aus der Tabelle.

Über das Ergebnis machst Du nun eine Abfrage mit einer Einschränkung in der Wherebedingung.

Meiner Meinung nach muss die einschränkende Wherebedingung in die Prozedure, da nur dort die Nutzung des Index sinnvoll möglich ist.

Letztlich machst Du aktuell sowas:

SQL-Code:

select feld1, feld2 from
(
  select TB.Feld1, TB.feld2 from Tabelle1 TB  -- ohne Einschränkung ist die Nutzung eines Index nicht sinnvoll
)
where Feld1 starting with 'A' and Feld2 starting with '7' -- und hier gibt es keinen Index, der genutzt werden könnte.

Sinngemäß sollte sowas gehen: (mit minimaler Datenmenge getestet und hingedaddelt)

SQL-Code:

SET TERM ^ ;
create procedure NEW_PROCEDURE(Start1 varchar(32), Start2 varchar(32))
  returns (Feld1 varchar(32), Feld2 varchar(32))
as
begin
  for
    select TB.Feld1, TB.feld2
    from Tabelle1 TB
    where TB.Feld1 starting with :Start1 and TB.Feld2 starting with :Start2
    group by TB.Feld1, TB.Feld2 
    into :Feld1, Feld2
  do
    suspend;
end^

SET TERM ; ^

Aufruf:

SQL-Code:

Select Feld1, Feld2 from NEW_PROCEDURE('A','7')

Zumindest sollte das mal einen Versuch wert sein.

Ansonsten Doku zu Rate ziehen: FOR SELECT ... INTO ... DO, zweites Beispiel. FireBird - Create PROCEDURE

[IBExpert]

wenn du auf einer sp einen select machst, dann wird dessen datenmenge immer wie Delphi.Narium
schon schrieb komplett ausgewertet (es sei denn da drin sind first oder rows) anweisungen,
das ist aber unwichtig in diesem Kontext.

Es ist wirklich do das die SP intern alle 86 mio records aklappert und
die mit dem Suspend an die ergebnismenge sendet, sprich das was dann
außerhalb der sp als where bedingung dann dessen ergebnisse noch einschränkt.

Im Gegensatz zu views, die eigentlich nur platzhalter für komplexe selects sind
und daher vom optimierer die intern benutzten mit anderen tabellen indiziert
abgefragt werden können, geht das bei sp gar nicht.

Beispiel

Code:

create procedure test
returns (tier varchar(20))
as
begin
  tier='Hund';
  suspend;
  tier='Katze';
  suspend;
  tier='Maus';
  suspend;
end

auch diese datenmenge kannst du mit einem select abfragen, per join mit
anderen daten verknüpfen, aber es ist offensichtlich, das da gar keine
tabelle intern benutzt wird. Ein Select außerhalb einer SP kann die
ergebnismenge zwar noch beliebig einschränken oder sortieren, der
optimierer in fb hab dabei auch nichts damit zu tun.