Also der Fehler SQL0666 ist so alt wie man mit SQL auf die AS/400 und nun IBM i zugreifen kann.
Der Optimizer schätzt eben die Zeit, die die Ausführung des SQL's wahrscheinlich dauern wird.
Zwar hat sich da immer mal wieder was getan, allerdings liegt der Optimizer leider auch häufig daneben.

Eine View (mit where) über die Tabelle zu bauen bringt für den Optimizer rein gar nichts.
Es wird immer über die Table selektiert und der SQL ggf. mit der Where.-Klausel aus der View ergänzt.
Die View hat außer für Schreibfaule aus SQL-Sicht keine Bedeutung.

Anders sieht es mit einem Index aus.
Mit dem neuen Optimizer (V6 oder erst V7) wird ein Index mit Where-Klausel (unsere gute alte LF mit Select/Omit) verwendet, wenn die where-klausel des SQL's mit dem des Index übereinstimmt.
Aber Achtung: wirklich ein Index und keine LF.

Trotz aller Indizierungen wird halt gerne der Fehler gemacht, bei den Where-und Join-Bedingungen nicht auf die korrekt Typisierung zu achten.
Da reicht schon ein Unterschied mit gepackt zu zoned, ins besonders bei unterschiedlichen Längen.
Hier hilft dann auch schon mal ein "cast(fromfield as totype)" um dem Optimizer zu helfen, den korrekten Index zu finden.
Ansonsten wird halt gerne ein Tablescan angewandt. Und wenn dann die Anzahl Zugriffe die Abfragezeit verlängert gibts halt einen SQL0666.
Das selbe gilt immer wieder für fehlende Indizes die zur gwünschten Where-Klausel passen müssen.
Hierbei kann man sich auch nicht immer auf die vorgeschlagenen Indizes verlassen.
Wenn man diese dann anlegt nimmt SQL sie dann doch nicht.

Mit unserer BI-Anwendung wird häufig per selbstgestricktem SQL vom Kunden auf die IBM i zugegriffen.
Hier beobachte ich das dann häufig, dass z.B. das Joblog gerne mit 1000den Meldung vollgeschrieben wird, dass eine Typanpassung erforderlich ist. Wenn dann auch noch alle paar Sekunden 1 Joblog mit 4000 Seiten erstellt wird, gibts auch schon mal eine 98%-Platte-Voll-Warnung.

Um dem SQL0666 aus dem Weg zu gehen, wird dann aus ODBC-Sicht gerne der Timeout auf 3600 oder schon mal 32000 Sekunden gesetzt obwohl der SQL dann tatsächlich in erheblich kürzerer Zeit ausgeführt wird.