Firebirdforum.de

In der FB-Sprachreferenz https://firebirdsql.org/file/documenta ... erenz.html
findet sich folgender Satz:

Wenn CONTAINING als Suchkriterium in DML-Abfragen verwendet wird, kann der Firebird-Optimizer einen Index der Suchspalte nutzen, sofern ein passender existiert.

In FB3 zumindest stimmt diese Aussage nicht. Ich habe es mit Dialect 1 und 3 getestet (sowohl mit numerischen als auch mit alphanumerischen Feldern, die natürlich jeweils einen expliziten Index mit deutlicher Selektivität haben), es werden exakt genauso viele Zugriffe wie mit LIKE durchgeführt.

Kann das evtl. jemand aufklären?

Guten Morgen,

CONTAINING wandelt sämtliche Werte intern in Strings um und sucht dann innerhalb dieser Zeichenketten nach dem Suchwert. Da Firebird aber keine indizierten Volltextsuchen unterstützt, wird auch kein Index verwendet.

Anders sieht das bei STARTING WITH aus. Hier kann der Optimizer auf die Indizies zurückgreifen, da der Startwert Verwendung findet. Gleiches müsste auch für LIKE XY% gelten. Ggf. müssen aber die Collations passen.

Die Aussage in der Dokumentation (auch in der englischen) zu CONTAINING ist damit m.E. nicht ganz vollständig. Derzeit gibt es eben NIE einen passenden Index für CONTAINING.

Vielleicht meldet sich noch jemand, der meine Aussagen ergänzen kann.

Gruß
Martin

Ggf. mal einen berechneten Index (Computed by) mit Cast in varchar(255) erstellen.
Anschließend einen

where cast(fx as varchar(255)) containing ....

Das Prinzip berechneter Indizes ist eben, dass die Where-Klausel exakt dem Ausdruck entspricht.
Der Vorteil der Indizierung ist eben, dass erst der Index durchsucht wird bevor auf die Satzversion zugegriffen wird und die Dekomprimierung erst noch stattfinden muss.

Zu der 2.5er Dokumentation gibt es seitens der Entwickler eine klare Aussage: die Doku ist an dieser Stelle falsch.
Ab Version 3.0 wurde dieser Part entfernt.

Gruß
Martin