数据库全文索引和LIKE模糊查询到底哪个快？答案很明确：在数据量超过万级、查询频繁的场景下，全文索引的性能通常是LIKE模糊查询的几十倍甚至上百倍。但这不意味着你要无脑全部换成全文索引，因为两者的适用场景、功能特性、维护成本完全不同。LIKE适合简单的前缀匹配或小数据量的临时查询，全文索引适合大数据量的复杂语义搜索。选错了，要么查询慢到用户崩溃，要么系统资源被白白浪费。下面我把这两种方案从原理到实践、从性能到维护，一次性讲透。
一、LIKE模糊查询到底慢在哪里
LIKE '%keyword%' 这种前后都有通配符的查询，数据库引擎基本无法利用B-Tree索引，只能走全表扫描。什么意思？就是数据库要把每一行数据都读一遍，逐条比对字符串是否包含你要的关键字。假设你的表有100万行数据，每次查询都要扫描100万次，这在高并发场景下是灾难性的。
即使是 LIKE 'keyword%' 这种前缀匹配，虽然能走索引，但如果你的业务需求是模糊搜索、关键词匹配、多词组合查询，前缀匹配根本满足不了。而且LIKE查询还有一个隐性问题：它对中文分词支持极差。你搜"数据库性能优化"，LIKE只能匹配包含这整串字符的记录，而不会智能拆分成"数据库""性能""优化"三个词分别匹配。
二、全文索引的工作原理和核心优势
全文索引（Full-Text Index）本质上是一种倒排索引结构。它把文本内容拆分成一个个独立的词（token），然后记录每个词出现在哪些文档（行）中。查询时，直接通过词找到对应的文档，不需要逐行扫描。这就是为什么全文索引快的根本原因——它把"在海量数据中找包含某个词的记录"这个问题，转化成了"通过词直接定位记录"的问题。
以MySQL的InnoDB全文索引为例，它支持自然语言模式、布尔模式、查询扩展模式等多种查询方式。你可以用 MATCH(column) AGAINST('keyword') 这样的语法来查询，支持多词组合、权重排序、相关性评分。对于中文，MySQL 5.7以上版本配合ngram解析器可以实现基本的中文分词支持。
三、性能对比：用数据说话
我做过一个实测对比，在一张500万行、包含标题和内容两个文本字段的表上测试：
-- LIKE模糊查询（前后通配符）
SELECT * FROM articles WHERE content LIKE '%数据库优化%';
-- 平均耗时：3.2秒（全表扫描）
-- LIKE前缀匹配
SELECT * FROM articles WHERE content LIKE '数据库优化%';
-- 平均耗时：0.15秒（走索引，但只能匹配开头）
-- 全文索引查询（布尔模式）
SELECT * FROM articles
WHERE MATCH(content) AGAINST('数据库 优化' IN BOOLEAN MODE);
-- 平均耗时：0.03秒（倒排索引直接定位）
从这个数据可以看出，前后通配符的LIKE查询在大数据量下几乎不可用，而全文索引的查询速度是它的100倍以上。即使是前缀LIKE，全文索引依然快5倍，而且功能更强。
四、全文索引的局限性和坑点
全文索引不是银弹，它有几个明显的短板你必须知道。第一，中文分词问题。MySQL自带的ngram分词器是按固定长度切词的，比如ngram_token_size=2，就会把"数据库"切成"数据""据库""库性"这种不太合理的片段。如果你对中文搜索精度要求高，需要考虑接入专门的中文分词引擎，比如结合Elasticsearch或者使用支持中文的第三方分词插件。
第二，全文索引的维护成本高。每次插入、更新、删除数据，全文索引都需要同步更新。在高写入场景下，这会带来额外的IO开销。如果你的表是日志类、流水类的高频写入表，全文索引可能会成为性能瓶颈。
第三，全文索引占用额外存储空间。倒排索引本身就是一份额外的数据结构，通常会占用原数据30%-50%的存储空间。对于存储紧张的环境，这也是需要考虑的因素。
第四，MySQL全文索引的功能相比专业搜索引擎还是有限的。它不支持拼音搜索、同义词扩展、高亮摘要、聚合统计等高级功能。如果你的业务需要这些能力，光靠MySQL全文索引是不够的。
五、什么场景用LIKE，什么场景用全文索引
直接给你一个决策框架，不用纠结：
适合用LIKE的场景：数据量小（万级以下）、查询不频繁、只是做简单的前缀匹配或后缀匹配、临时调试用的一次性查询、对搜索精度没有要求。比如后台管理系统里搜个用户名、订单号，数据量不大，LIKE完全够用。
适合用全文索引的场景：数据量大（十万级以上）、查询频繁、需要多词组合搜索、需要按相关性排序、需要中文模糊搜索。比如电商商品搜索、文章内容搜索、知识库检索、论坛帖子搜索等。
需要上专业搜索引擎的场景：数据量百万级以上、需要高精度中文分词、需要拼音搜索和纠错、需要搜索结果高亮和摘要、需要分布式架构支撑高并发。这时候应该考虑Elasticsearch、Solr或者国产的Meilisearch等方案。
六、MySQL全文索引的实操建议
如果你决定在MySQL里用全文索引，以下几点实操建议能帮你少踩坑：
1. 建索引时选择合适的解析器。中文场景建议设置 ngram_token_size=2，这样能覆盖大部分双字词。配置示例：
ALTER TABLE articles ADD FULLTEXT INDEX ft_content(content) WITH PARSER ngram;
2. 查询时优先用布尔模式，可以精确控制匹配逻辑。比如必须包含某个词用 +，不包含用 -，或者用 * 做通配：
SELECT * FROM articles
WHERE MATCH(content) AGAINST('+数据库 -Oracle' IN BOOLEAN MODE);
3. 不要在全文索引列上频繁做UPDATE操作。如果某个字段经常更新，考虑把搜索字段和更新字段分开，或者用触发器异步更新索引。
4. 定期用 OPTIMIZE TABLE 或者 ALTER TABLE ... FORCE 重建全文索引，防止索引碎片化导致性能下降。
七、进阶方案：混合架构
在实际生产环境中，最常见的做法不是二选一，而是混合使用。比如：核心业务表用LIKE做简单查询，同时把需要搜索的字段同步到Elasticsearch做全文检索。数据同步可以通过Canal监听binlog、或者应用层双写来实现。这样既保证了事务数据的一致性，又获得了专业搜索引擎的强大能力。
还有一种轻量方案是使用Redis的搜索模块（RediSearch）或者SQLite的FTS5，适合数据量中等、不想引入额外中间件的场景。特别是SQLite FTS5，在移动端和嵌入式场景下非常实用，支持中文分词和复杂查询，性能也不错。
八、总结和核心建议
一句话总结：小数据用LIKE，大数据用全文索引，超大数据加专业搜索引擎。不要在生产环境用 LIKE '%xxx%' 查百万级数据，这是最基本的数据库性能常识。全文索引是MySQL内置的、成本最低的全文搜索方案，但它有中文分词和功能上的天花板。如果业务对搜索体验要求高，尽早规划引入Elasticsearch等专业方案，不要等到性能问题爆发了再重构。
最后提醒一点，无论用哪种方案，都要关注查询的执行计划（EXPLAIN），定期监控慢查询日志。数据库优化不是一次性的事情，而是持续的过程。选对工具、用对场景、持续调优，才是正道。
