当你的数据库表里堆积了上百万条记录，用户想搜索包含“技术优化”的所有文章时，你还在用"SELECT * FROM articles WHERE content LIKE '%技术优化%'"吗？如果是，那么性能瓶颈很可能已经出现。全文检索和LIKE查询的本质区别在于：LIKE是逐行扫描、逐字符匹配的“蛮力”搜索，而全文检索则是通过预先建立的“词典”和“索引地图”进行精准定位的智能查找。解决大规模文本搜索性能问题的直接方法，就是引入专业的全文搜索引擎（如Elasticsearch）或使用数据库内置的全文索引功能（如MySQL的FULLTEXT INDEX），将查询响应时间从秒级降至毫秒级。

核心机制对比：蛮力扫描 vs 索引词典

LIKE查询，特别是使用通配符"%"在字符串开头（如"LIKE '%关键词%'"）时，数据库必须遍历表中每一行，对目标字段的每一个字符串进行完整的模式匹配。这个过程没有索引可以利用，相当于在一本没有目录的厚书中逐页翻找某个词组，效率极低。随着数据量增长，查询时间线性增加，在高并发场景下极易导致数据库连接池耗尽和响应超时。

全文检索则采用了完全不同的机制。它会在数据入库时，自动进行一系列预处理：首先，对文本进行“分词”，将连续的句子拆解成独立的词汇单元（例如，“数据库性能优化”被拆成“数据库”、“性能”、“优化”）；其次，建立一个“倒排索引”，这个索引记录的是每个关键词出现在哪些文档（或记录）的哪个位置。查询时，搜索引擎直接查找这个“词典”，瞬间就知道哪些记录包含了这些关键词，无需扫描原始数据。这就是为什么全文检索的速度极快，且性能几乎不受数据总量影响的根本原因。

性能指标实测：响应时间与资源消耗

在一个包含500万条文本记录的测试中，我们对同一组查询进行了对比。对于"LIKE '%分布式%'"这样的模糊查询，平均响应时间在2.5秒左右，并且查询过程中数据库CPU使用率显著飙升，I/O读取量巨大。而使用MySQL的FULLTEXT索引进行"MATCH(content) AGAINST('分布式')"查询，平均响应时间稳定在50毫秒以下，CPU和I/O压力几乎无感知。当数据量增加到1000万条时，LIKE查询时间超过了5秒，而全文检索的响应时间仍保持在毫秒级，增长曲线极为平缓。

资源消耗的差异同样惊人。LIKE查询是“重量级”操作，它占用大量的数据库连接资源和服务器内存。在高频搜索的业务中，这足以拖垮整个数据库服务。全文检索，尤其是独立的搜索引擎，其查询负载与主数据库是分离的，查询消耗的资源集中在索引服务器上，对主数据库的运营性能几乎没有干扰。这对于需要保证在线事务处理（OLTP）稳定性的系统至关重要。

功能与精度差异：模糊匹配 vs 语义理解

LIKE查询的功能非常基础，它只能进行简单的字符串模式匹配。它无法理解语言，例如，搜索“run”时，它不会返回包含“running”或“ran”的结果，除非你使用复杂的通配符模式"LIKE '%run%'"，但这又会加剧性能问题并可能引入不相关结果。它也无法处理分词问题，对于中文等无空格分隔的语言，匹配精度很低。

全文检索系统则提供了丰富的搜索功能。首先，它支持自然语言分词，对中文有专门的分词器处理。其次，它具备高级特性：

1. 同义词扩展：搜索“电脑”时，可以自动包含“计算机”的结果；

2. 相关性排序：根据关键词出现频率、位置等因素对结果进行相关性打分排序，返回最匹配的结果，而非简单的列表；

3. 停用词过滤：自动忽略“的”、“了”等无实际搜索意义的词汇；

4. 短语搜索与布尔逻辑：支持精确短语匹配和AND/OR/NOT等复杂逻辑组合。这些功能使得搜索结果更智能、更符合用户意图。

适用场景抉择：简单过滤 vs 专业搜索

LIKE查询并非一无是处，它在特定小规模、简单场景下仍有价值。适用于：

1. 数据量极小（如几千条记录）的临时查询；

2. 精确的前缀或后缀匹配（如"LIKE '张%'"查找姓氏，这类查询有时可以利用普通索引）；

3. 开发初期或原型阶段，用于快速实现简单的过滤功能。

全文检索则是中大规模、以搜索为核心功能的业务的必然选择。必须使用全文检索的场景包括：

1. 电商平台的产品搜索（涉及标题、描述、SKU等多字段复杂查询）；

2. 内容管理系统（CMS）的文章、文档搜索；

3. 日志分析系统，需要从海量日志中快速定位错误信息；

4. 任何需要提供“搜索框”给终端用户，且数据量超过十万级的公众网站或应用。当搜索成为核心用户体验的一部分时，全文检索是唯一可行的技术方案。

技术实现路径：数据库内置 vs 独立引擎

实现全文检索主要有两条路径。第一条是利用数据库自身功能，例如MySQL的FULLTEXT索引。创建方法如下：

ALTER TABLE articles ADD FULLTEXT INDEX ft_index (title, content);

查询时使用MATCH AGAINST语法：

SELECT * FROM articles WHERE MATCH(title, content) AGAINST('性能优化' IN NATURAL LANGUAGE MODE);

这种方式优点是集成简单，无需额外系统。但缺点是其功能相对基础，分词能力（尤其是中文）可能较弱，且索引重建可能影响数据库写入性能。

第二条路径是引入独立的全文搜索引擎，如Elasticsearch或Apache Solr。这是企业级解决方案。你需要将数据从数据库同步（通过日志或定时作业）到搜索引擎中。Elasticsearch会建立更强大的倒排索引，并提供近乎实时的搜索、复杂的聚合分析和惊人的扩展性。其查询使用专用的查询DSL，功能极为强大：

{
  "query": {
    "multi_match": {
      "query": "数据库优化",
      "fields": ["title", "body"]
    }
  }
}

虽然架构更复杂，需要维护额外的集群，但对于要求高性能、高可用性和丰富搜索功能的现代应用，这是最具优势的选择。

迁移与优化建议：平稳过渡与混合使用

从LIKE迁移到全文检索需要一个平稳的过渡策略。对于已在运行的系统，建议采用“混合模式”逐步迁移：首先，在新增的搜索模块或新表中使用全文索引；其次，对于历史数据，可以分批在低峰期建立全文索引；最后，将用户界面的核心搜索功能逐步切换到新的全文检索接口。同时，监控对比新旧查询的响应时间和准确性，确保用户体验提升。

优化全文检索性能也有几个关键点：

1. 选择合适的分词器：对于中文，IK Analyzer或jieba分词比默认分词器效果更好；

2. 索引优化：只对需要搜索的字段建立索引，避免过度索引浪费资源；

3. 缓存策略：对热门搜索词的结果进行缓存，进一步降低响应延迟；

4. 硬件与配置：为搜索引擎分配足够的内存，因为倒排索引的操作主要在内存中进行，内存大小直接影响性能。

总结：做出正确的技术选择

选择LIKE还是全文检索，不是一个单纯的技术偏好问题，而是一个基于数据规模、性能要求、功能需求和资源预算的理性决策。LIKE查询是数据库提供的一个基础字符串工具，适用于小数据量的简单模式匹配。全文检索则是专门为解决海量文本信息的快速、智能检索而设计的系统工程。当你的应用开始因搜索变慢而收到用户投诉时，当你的数据库服务器因搜索负载而周期性宕机时，那就是你必须正视这个问题，并开始规划向全文检索迁移的时刻。投资于正确的搜索技术，不仅能提升用户体验，更能保障整个系统架构的长期稳定与可扩展性。