答え。

問題の歴史:
当初、SQLは主に構造化データの処理に使用されており、テキストフィールドの検索はLIKEのような単純な操作に制限されていました。テキスト情報の量が増加するにつれて、記事、メッセージ、ブログなどの大きなテキストに対して迅速かつ柔軟に検索を行う必要が生じました。

問題:
標準的なSQLツール（LIKE / ILIKE）は、大量のテキストに対してうまく機能せず、関連性、形態素、単語間の距離を考慮して単語を効果的に見つけることができません。これによりパフォーマンスの低下と、検索時の応答が遅すぎることがあります。

解決策:
このようなタスクには、FTS（フルテキスト検索）として知られるデータベース内のメカニズムが使用されます。たとえば、フルテキストインデックスや特別な演算子（CONTAINS、MATCH AGAINST、tsvector、tsquery）です。これらのインデックスは「単語カード」（逆インデックス）を構築し、テキストの検索を数十倍速くします。

コード例（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"');

主な特徴:

特別なフルテキストインデックスに基づいて機能し、通常のインデックスとは分離されています。
関連性、レンマ化、ストップワードの認識、複雑な条件（NOT、OR、近接）をサポートします。
大量のデータが変更されるときにインデックスの維持が必要—定期的な再インデックス化。

ダミー質問。

LIKEを使用した検索とフルテキスト検索の違いは何ですか？
LIKEは、テキストにインデックスを使用せず、大量のデータに対しては遅いパターン比較操作です。フルテキストは特殊なインデックスを使用し、形態素、関連性を考慮します。

例:

SELECT * FROM articles WHERE body LIKE '%database%';
-- 遅い、ランク付けがない

SELECT * FROM articles WHERE MATCH(body) AGAINST ('database');
-- 速い、ランク付き

大量の挿入や削除の際にフルテキストインデックスはどうなりますか？
テキストフィールドの大規模な変更後、インデックスは古くなります（場合によっては自動的に更新されますが、手動が必要なこともあります）、パフォーマンスを回復するためにインデックスの再構築が必要です。

-- MSSQLの場合
ALTER FULLTEXT INDEX ON Documents START FULL POPULATION;

JSONやXML型の列にフルテキストインデックスを使用できますか？
いいえ、ほとんどのフルテキストエンジンにはJSON/XML構造への直接サポートがありません。このようなデータは文字列フィールドに抽出するか、専用のパーサーや外部ツール（例：Elasticsearch）を使用する必要があります。

一般的な間違いとアンチパターン

大きなテーブルに対してLIKE '%word%'を使用すると、壊滅的なパフォーマンス
再インデックス化が行われず、検索が関連性を失う
言語の特徴やストップワードを考慮しない
追加のリソースなしに数ギガバイトのデータを同時にインデックス化

実際の例

ネガティブケース

企業は数千万件のアーティクルを保存していました。検索にはLIKE '%word%'が使用されており、IT部門は定期的なタイムアウトについて不満を言っていました。ユーザーは結果を得るのに10分以上待っていました。

プラス:

追加のライセンスや設定は不要
簡単な実装

マイナス:

特に大量の場合、パフォーマンスが悪い
システムの応答時間が非現実的
検索結果が不正確（単語の形を考慮しない）

ポジティブケース

フルテキスト検索（MySQLのFULLTEXT INDEX）を導入しました。検索が100倍速くなり、「類似」の単語やフレーズを検索できるようになり、ランキングも追加されました。