SQL Server Volltextsuche mit klaren Suchregeln aufbauen

Ein Suchfeld mit LIKE '%term%' über große Artikeltexte kann mit wachsendem Bestand teuer werden. Die SQL-Server-Volltextsuche bietet einen anderen Zugriff, verändert aber auch die Bedeutung eines Treffers. Sie indiziert sprachliche Wörter beziehungsweise Tokens und nicht jede denkbare Zeichenfolge. Ein unüberlegter Ersatz kann deshalb schneller und trotzdem weniger hilfreich sein.

Trennen Sie die Anforderungen. Ein exakter Produktcode, ein Wort im Fließtext, eine Phrase und eine beliebige Teilzeichenfolge sind verschiedene Suchfragen. Für den Code kann ein normaler indizierter Gleichheitsvergleich passen, für Wörter eine sprachabhängige Volltextsuche. Nicht jedes Feld muss denselben Mechanismus verwenden.

Die Sprache ausdrücklich festlegen

Das Beispiel erstellt dauerhafte Übungsobjekte. Verwenden Sie eine entbehrliche Datenbank mit installierter Volltextsuche und passenden Einrichtungsrechten.

-- Run only in a disposable database with Full-Text Search installed.
CREATE TABLE dbo.SearchArticleDemo (
    ArticleId int NOT NULL CONSTRAINT PK_SearchArticleDemo PRIMARY KEY,
    Title nvarchar(200) NOT NULL,
    Body nvarchar(max) NOT NULL
);
INSERT dbo.SearchArticleDemo VALUES
(1, N'Index design', N'An index can reduce reads for selective queries.'),
(2, N'Backup planning', N'Restore tests verify that backups are usable.'),
(3, N'Query performance', N'Query performance depends on access paths and data.');
CREATE FULLTEXT CATALOG SearchArticleDemoCatalog;
CREATE FULLTEXT INDEX ON dbo.SearchArticleDemo
    (Title LANGUAGE 1033, Body LANGUAGE 1033)
KEY INDEX PK_SearchArticleDemo
ON SearchArticleDemoCatalog
WITH CHANGE_TRACKING AUTO;

Der Volltextschlüssel nutzt eine eindeutige, nicht leere Kennung. Beide Textspalten verwenden englische Regeln mit LCID 1033. Die Sprache beeinflusst Wortzerlegung und Flexionsbehandlung und ist nicht bloß eine Oberflächenbeschriftung.

Eine mehrsprachige Anwendung muss festlegen, wie die Sprache der indizierten Spalte zu den enthaltenen Dokumenten passt. Viele unterschiedliche Sprachen unter einer beliebigen Einstellung können die Relevanz verschlechtern. Getrennte lokalisierte Datenhaltung oder ein spezialisierter Suchdienst kann geeigneter sein, wenn die Anforderungen dieses Modell übersteigen.

CHANGE_TRACKING AUTO verarbeitet Änderungen asynchron. Ein erstellter Index ist deshalb nicht automatisch bereits vollständig gefüllt. Auch ein bestätigter Artikelwechsel kann verzögert sichtbar werden. Keine Treffer unmittelbar nach der Einrichtung beweisen daher keinen falschen Suchausdruck.

Rangfolge nachvollziehbar ausgeben

FREETEXTTABLE nimmt natürlichsprachigen Suchtext an und liefert Schlüssel mit Rangwerten.

DECLARE @Search nvarchar(4000) = N'index performance';
SELECT TOP (10) a.ArticleId, a.Title, ft.[RANK]
FROM FREETEXTTABLE(
    dbo.SearchArticleDemo, (Title, Body), @Search, LANGUAGE 1033
) AS ft
JOIN dbo.SearchArticleDemo AS a ON a.ArticleId = ft.[KEY]
ORDER BY ft.[RANK] DESC, a.ArticleId;

Die konkreten Rangwerte hängen von Inhalt und Anfrage ab. Sie sind keine kalibrierte Wahrscheinlichkeit. ArticleId schafft eine eindeutige Reihenfolge bei gleichem Rang. Der Suchtext bleibt hier absichtlich englisch, weil auch die Übungsdokumente englisch sind.

FREETEXT eignet sich für gewöhnliche eingegebene Wörter. CONTAINS und CONTAINSTABLE bieten eine strukturierte Grammatik für Phrasen, Präfixe und logische Verknüpfungen. Ein Präfix sucht Wortanfänge, nicht beliebige Fragmente innerhalb jedes Wortes. Satzzeichen und Wortzerlegung können technische Codes anders behandeln als eine einfache Teilzeichenfolgensuche.

Übergeben Sie Eingaben als SQL-Parameter. Bei strukturierter Volltextsyntax verhindert das SQL-Verkettung, macht aber nicht jeden Text zu einer gültigen Suchanfrage. Prüfen oder erzeugen Sie die erlaubte Grammatik zusätzlich und melden Sie ungültige Eingaben verständlich.

Stopplisten können häufige Wörter entfernen. Prüfen Sie Anfragen nur aus Stoppwörtern, zitierte Phrasen, Kennungen mit Bindestrichen und sprachtypische Formen. Definieren Sie das Verhalten für leere oder nicht sinnvoll durchsuchbare Eingaben, statt daraus einen unbeschränkten Tabellenscan zu machen.

Aktualität, Filter und Relevanz prüfen

Die Abfrage hilft, fehlende Installation und laufende Befüllung zu unterscheiden.

SELECT FULLTEXTSERVICEPROPERTY('IsFullTextInstalled') AS Installed,
       OBJECTPROPERTYEX(OBJECT_ID(N'dbo.SearchArticleDemo'),
           'TableFulltextPopulateStatus') AS PopulationStatus;

Bei fehlenden Treffern gehören Befüllungsstatus und Volltextdiagnostik zur Untersuchung. Ein Leerlaufstatus allein beweist nicht, dass jedes erwartete Dokument korrekt indiziert wurde. Prüfen Sie konkrete neue Kennungen und darin enthaltene Suchwörter sowie gegebenenfalls Fehler der Dokumentverarbeitung.

Berechtigungen und Mandantenfilter müssen vor der Rückgabe gelten. Eine kleine global bestplatzierte Kandidatenmenge erst anschließend nach Mandant zu filtern kann zu wenige Ergebnisse liefern, obwohl genügend passende Mandantendokumente vorhanden sind. Prüfen Sie Vollständigkeit und Plan der tatsächlichen Filterstrategie.

Verwenden Sie repräsentative Texte und bekannte Suchfälle. Messen Sie Dauer und Leseaufwand, untersuchen Sie aber ebenso fehlende Dokumente und irreführende Treffer. Eine schnelle Antwort kann die Suchaufgabe trotzdem verfehlen.

Beschreiben Sie Aktualität und Suchbedeutung schließlich in verständlichen Produktbegriffen. Nutzer sollten erkennen, ob exakte Codes oder sprachliche Inhalte gesucht werden und warum ein neuer Text möglicherweise kurz verzögert erscheint.

Technische Referenzen: Microsoft Learn: Full-text search · Microsoft Learn: FREETEXTTABLE · Microsoft Learn: CONTAINS.