答案。

问题背景：
最初，SQL主要用于处理结构化数据，在文本字段中的搜索仅限于简单操作，如LIKE。随着文本信息量的增加，快速、灵活地搜索大量文本（如文章、消息、博客等）的需求应运而生。

问题：
标准的SQL工具（LIKE/ILIKE）在处理大文本量时效果不佳，无法有效找到相关性、考虑形态学或单词间距的词。这可能导致性能下降和搜索响应时间过长。

解决方案：
为此类任务使用数据库管理系统中内置的全文搜索机制（Full-Text Search, 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"');

关键特点：

基于与普通索引分开的特殊全文索引进行操作。
支持相关查询、词形还原、停用词识别和复杂条件（非、或、接近）。
在数据大量变更时需要维护索引——定期重新索引。

反向问题。

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%'— 性能灾难
未执行重新索引，搜索结果变得不相关
未考虑语言特性和停用词
同时对几个GB的数据进行索引而未提供额外资源

实际案例

负面案例

某公司存储了数千万条文章记录。搜索使用了LIKE '%слово%'。IT部门抱怨经常超时，用户等待结果超过10分钟。

优点：

不需要额外的许可证或设置
实现简单

缺点：

性能差，尤其在大数据量下
系统响应时间不切实际
搜索结果不正确（未考虑词形）

正面案例

实施了Full-Text Search（MySQL中的FULLTEXT INDEX）。搜索速度提高了100倍，可以搜索“相似”的单词和短语，并增加了排名。