Odpowiedź.

Historia pytania:
Początkowo SQL był używany głównie do pracy ze danymi strukturalnymi, gdzie wyszukiwanie w polach tekstowych ograniczało się do prostych operacji, takich jak LIKE. Wraz ze wzrostem ilości informacji tekstowej pojawiła się potrzeba szybkiego i elastycznego wyszukiwania w dużych tekstach: w artykułach, wiadomościach, blogach itp.

Problem:
Standardowe narzędzia SQL (LIKE/ILIKE) słabo radzą sobie z dużymi objętościami tekstu i nie potrafią efektywnie znajdować słów według relewantności, uwzględniając morfologię lub odległość między słowami. Może to prowadzić do utraty wydajności i zbyt długich czasów reakcji podczas wyszukiwania.

Rozwiązanie:
Dla takich zadań wykorzystuje się mechanizmy wyszukiwania pełnotekstowego (Full-Text Search, FTS), wbudowane w systemy zarządzania bazami danych, takie jak Indeksy Pełnotekstowe i specjalne operatory (CONTAINS, MATCH AGAINST, tsvector, tsquery). Takie indeksy tworzą „kartę słów” („indeks inwersyjny”), przyspieszając wyszukiwanie w tekstach nawet kilkadziesiąt razy.

Przykład kodu (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"');

Kluczowe cechy:

Działa na bazie specjalnych indeksów pełnotekstowych, oddzielonych od zwykłych.
Obsługuje zapytania z relewantnością, lematyzacją, uznawaniem słów stopowych i złożonych warunków (NIE, LUB, bliskość).
Wymaga utrzymania indeksu przy masowych zmianach danych — okresowa reindeksacja.

Pytania z podstępem.

Czym różni się wyszukiwanie za pomocą LIKE od wyszukiwania pełnotekstowego?

LIKE — to prosta operacja porównania z wzorem, nie wykorzystująca indeksów tekstowych, wolna dla dużych objętości. Wyszukiwanie pełnotekstowe używa specjalnego indeksu i może uwzględniać morfologię oraz relewantność.

Przykład:

SELECT * FROM articles WHERE body LIKE '%database%';
-- wolno, brak sortowania

SELECT * FROM articles WHERE MATCH(body) AGAINST ('database');
-- szybko, z sortowaniem

Co dzieje się z indeksem pełnotekstowym przy masowych wstawieniach lub usunięciach?

Po masowych zmianach w polach tekstowych indeks staje się przestarzały (czasami — automatycznie, czasami — ręcznie) i konieczne jest przeprowadzenie odbudowy indeksu w celu przywrócenia wydajności.

-- Dla MSSQL
ALTER FULLTEXT INDEX ON Documents START FULL POPULATION;

Czy można używać indeksów pełnotekstowych do wyszukiwania w kolumnach typu JSON lub XML?

Nie, większość silników pełnotekstowych nie obsługuje bezpośrednio struktur JSON/XML; takie dane należy wydobyć do pola tekstowego lub zastosować specjalne parsery/ewentualne narzędzia (np. Elasticsearch).

Typowe błędy i antywzorce

Używanie operatora LIKE '%word%' na dużych tabelach — katastrofalna wydajność
Reindeksacja nie jest wykonywana, wyszukiwanie staje się nierelewantne
Nie uwzględniane są cechy języków i słów stopowych
Indeksowanie jednocześnie kilku gigabajtów danych bez dodatkowych zasobów

Przykład z życia

Negatywny przypadek

Firma przechowywała dziesiątki milionów rekordów artykułów. Do wyszukiwania używano LIKE '%słowo%'. Dział IT skarżył się na regularne timeouty, użytkownicy czekali na wyniki wyszukiwania 10+ minut.

Plusy:

Brak potrzeby dodatkowych licencji lub konfiguracji
Prosta implementacja

Minusy:

Słaba wydajność, szczególnie przy dużych objętościach
Nierealistyczne czasy odpowiedzi systemu
Nieprawidłowe wyniki wyszukiwania (brak uwzględnienia formy słowa)

Pozytywny przypadek

Wdrożono wyszukiwanie pełnotekstowe (FULLTEXT INDEX w MySQL). Wyszukiwanie stało się do 100 razy szybsze, pojawiła się możliwość wyszukiwania „podobnych” słów i fraz, dodano sortowanie.