索引在全文搜索与模糊查询中的表现差异
在数据库查询中，索引是提升性能的核心工具，但它在处理全文搜索和模糊查询时的表现却有显著差异。全文搜索依赖倒排索引快速定位关键词，而模糊查询（如LIKE '%关键词%'）往往因无法有效利用索引导致全表扫描。理解这些差异，有助于优化查询策略。
索引在全文搜索中的高效运作机制
全文搜索的索引结构专为文本匹配设计，通常采用倒排索引。它会将文档中的每个单词映射到其出现的位置，从而在查询时直接跳过无关数据。例如，当搜索“数据库优化”时，倒排索引能瞬间定位所有包含该短语的文档，无需逐行扫描。这种机制使得全文搜索在海量文本中仍能保持毫秒级响应，尤其适合搜索引擎或内容管理系统。
相比之下，模糊查询中的通配符（如%或_）会破坏索引的连续性。即使字段上建有B-tree索引，当查询以通配符开头时（如'%数据库'），数据库无法利用索引的前缀匹配特性，只能退化为全表扫描。这意味着随着数据量增长，模糊查询的性能会急剧下降，而全文搜索的索引优势则愈发明显。
索引在模糊查询中的局限性：为何性能会退化
通配符对索引路径的阻断效应
模糊查询的常见写法“LIKE '%关键词%'”要求匹配字符串中任意位置出现的关键词。B-tree索引依赖有序的键值结构，只能高效处理前缀匹配（如'关键词%'）。当通配符出现在左侧时，索引的二分查找算法失效，数据库不得不遍历所有索引条目甚至回表读取完整数据。对于百万级数据表，一次模糊查询可能消耗数秒，而相同条件下的全文搜索仅需几毫秒。
索引在模糊查询中的替代方案与代价
部分数据库支持前缀索引或基于函数的索引来缓解模糊查询压力。例如，为字段添加“反向索引”或使用“%关键词”的特定模式。但这些方法往往需要额外存储空间，且无法覆盖所有通配符场景。更关键的是，当模糊查询包含复杂模式（如'%关键%词%'）时，任何索引都难以生效，最终只能依赖全表扫描。这揭示了索引在模糊查询中的根本局限——它无法处理非确定性的位置匹配。
从索引差异看查询场景的选择策略
在实际应用中，应根据查询类型选择索引策略。全文搜索适合需要精准匹配关键词、短语或支持分词逻辑的场景，如博客搜索、产品描述检索。此时应使用全文索引（如MySQL的FULLTEXT或Elasticsearch的倒排索引），并配置合适的分词器。而模糊查询更适合少量数据或明确的前缀匹配需求，如用户输入“abc”时自动补全为“abc%”。对于必须使用模糊查询的场景，可考虑限制查询范围，例如仅对短文本字段或添加额外的过滤条件。
索引优化实践：平衡全文搜索与模糊查询的性能
当系统同时需要两种查询能力时，可采取混合策略。例如，将频繁模糊查询的字段冗余存储为倒排索引的副本，或通过Elasticsearch等专用引擎处理全文搜索，关系数据库仅负责结构化查询。另外，利用覆盖索引减少回表次数，或对模糊查询字段建立哈希索引（如PostgreSQL的trgm索引），能在特定模式下提升效率。但需注意，任何优化都需权衡写入性能与存储开销——全文索引的构建和维护成本远高于普通B-tree索引。
总结而言，索引在全文搜索中通过倒排索引实现高效定位，而在模糊查询中因通配符破坏索引结构而表现不佳。理解这种差异后，开发者应根据数据规模、查询频率和匹配精度选择合理方案：优先使用全文搜索处理文本匹配，对模糊查询限定使用场景或引入专用索引类型。最终，平衡查询性能与资源消耗，才能让索引真正成为数据检索的加速器而非瓶颈。