Antwort.

Historieller Kontext:
Ursprünglich wurde SQL hauptsächlich für die Arbeit mit strukturierten Daten verwendet, wobei die Suche in Textfeldern auf einfache Operationen wie LIKE beschränkt war. Mit dem Anstieg des Textdatenvolumens entstand die Notwendigkeit, schnell und flexibel in großen Texten zu suchen: in Artikeln, Nachrichten, Blogs usw.

Problem:
Standard SQL-Werkzeuge (LIKE/ILIKE) funktionieren schlecht mit großen Textmengen und können Worte nicht effektiv nach Relevanz, Morphologie oder Abständen zwischen Wörtern finden. Dies kann zu Leistungsproblemen und zu langen Antwortzeiten bei der Suche führen.

Lösung:
Für solche Aufgaben werden Volltextsuchmechanismen (Full-Text Search, FTS) verwendet, die in Datenbanksysteme integriert sind, z. B. Volltextindexe und spezielle Operatoren (CONTAINS, MATCH AGAINST, tsvector, tsquery). Solche Indizes erstellen eine „Wortkarte“ („invertierter Index“), was die Suche in Texten um das Zehnfache beschleunigt.

Codebeispiel (SQL Server):

CREATE FULLTEXT CATALOG ftCatalog AS DEFAULT;
CREATE FULLTEXT INDEX ON Documents(Content) KEY INDEX PK_Documents;

SELECT * FROM Documents WHERE CONTAINS(Content, '"SQL programming"');

Wichtige Merkmale:

Funktioniert auf der Basis spezieller Volltextindizes, die von normalen Indizes getrennt sind.
Unterstützt Anfragen mit Relevanz, Lemmatisierung, Erkennung von Stoppwörtern und komplexen Bedingungen (NICHT, ODER, Nähe).
Erfordert die Pflege des Indexes bei massiven Datenänderungen — regelmäßige Neuanlage des Indexes.

Versteckte Fragen.

Was unterscheidet die Suche mit LIKE von der Volltextsuche?

LIKE ist eine einfache Vergleichsoperation mit einem Muster, die keine Indizes für Text verwendet und bei großen Datenmengen langsam ist. Volltext verwendet einen speziellen Index und kann Morphologie und Relevanz berücksichtigen.

Beispiel:

SELECT * FROM articles WHERE body LIKE '%database%';
-- langsam, keine Rangordnung

SELECT * FROM articles WHERE MATCH(body) AGAINST ('database');
-- schnell, mit Rangordnung

Was passiert mit dem Volltextindex bei massiven Einfügungen oder Löschungen?

Nach massiven Änderungen an den Textfeldern wird der Index veraltet (manchmal automatische Aktualisierung, manchmal manuell), und es ist notwendig, den Index neu zu erstellen, um die Leistung wiederherzustellen.

-- Für MSSQL
ALTER FULLTEXT INDEX ON Documents START FULL POPULATION;

Kann man Volltextindizes für die Suche in Spalten vom Typ JSON oder XML verwenden?

Nein, die meisten Volltextsuchmaschinen bieten keine direkte Unterstützung für JSON/XML-Strukturen; solche Daten müssen entweder in ein Textfeld extrahiert oder spezielle Parser/externe Tools (z.B. Elasticsearch) verwendet werden.

Typische Fehler und Anti-Pattern

Verwendung des Operators LIKE '%word%' in großen Tabellen — katastrophale Leistung
Neuanlage des Indexes wird nicht durchgeführt, Suche wird irrelevant
Sprachspezifische Besonderheiten und Stoppwörter werden nicht berücksichtigt
Indizierung von mehreren Gigabyte Daten ohne zusätzliche Ressourcen

Beispiel aus dem Leben

Negativer Fall

Ein Unternehmen speicherte Dutzende Millionen von Artikelaufzeichnungen. Die Suche verwendete LIKE '%Wort%'. Die IT-Abteilung berichtete von häufigen Timeouts, Benutzer warteten über 10 Minuten auf Suchergebnisse.

Vorteile:

Keine Notwendigkeit für zusätzliche Lizenzen oder Konfigurationen
Einfache Implementierung

Nachteile:

Schwache Leistung, insbesondere bei großen Volumina
Unrealistische Antwortzeiten des Systems
Falsche Suchergebnisse (keine Berücksichtigung von Wortformen)

Positiver Fall

Die Implementierung von Full-Text Search (FULLTEXT INDEX in MySQL) wurde durchgeführt. Die Suche gab bis zu 100 Mal schnellere Ergebnisse zurück, es war möglich, „ähnliche“ Wörter und Phrasen zu suchen, und eine Rangordnung wurde hinzugefügt.