Das muss wohl am SQL-Overhead liegen.

@Fuerchau: Die Werte sind schon für 100.000 Aufrufe (wie in der ersten Frage angegeben). Das "Into" hatte ich zur Übersicht rausgenommen, die Aufrufe fanden mit SELECT INTO statt. Visual Explain zeigt auch an, das der absteigende Index nicht genommen wird.

@Bender: Die Abfrage mit gültig_bis und BETWEEN dauerte (ohne Index Optimierung und View) etwas länger als die beiden anderen. Vielleicht sind die Anzahl der Sätze, die derzeit in der Tabelle vorhanden sind, auch zu gering um einen Unterschied festzustellen.

Ich hatte die Frage einfach mal in dem Raum gestellt, da ich immer wieder auf diese Art der Abfrage stoße. Vielleicht hätte es ja einen eleganteren SQL Weg gegeben, dieses Problem zu lösen (RPG hat ja auch Operationen für diesen Art des Zugriffs).
Besonders in SQL-Abfrage, die einen Wert aus der "Gültig_AB" Tabelle dazu holen müssen, wäre es interessant. Die Abfrage ist dann sehr kompliziert, Select mit Unterselect auf "Gültig_AB" Tabelle und darauf wieder Unterselect für die MAX() Funktion. Mehrere 1000 Sätze kommen dann schnell zustande, welche die Unterabfrage dann wieder auslösen und den Geschwindigkeitsunterschied bemerkbar machen.

Sicherlich kann man die Funktion auch mit Stored-Procedure implementieren (mit allen möglichen Optimierung, Deterministic etc). Aber hier wäre der Optimizer wieder ein bisschen außen vor, falls es doch mal diese Art der Abfragen optimieren könnte. Und um die Abfrage in der Procedure schnell zu bekommen müssten man wieder auf RPG zurückgreifen, was wir in unsere Java-Umgebung nicht mehr so gerne möchten.