从5秒到0.02秒！MySQL全文索引性能优化实录

“搜个口红，页面转圈5秒才出结果，用户直接关 App。

”

这不是段子，是上周某电商大促的真实监控报警。

后台一查，SQL 里那句 `LIKE ‘%哑光%’`，把 CPU 打到90%，直接把促销流量腰斩。

别急着骂产品乱提需求，问题实则卡在 MySQL 的模糊查询天生瘸腿。

`LIKE ‘%关键词%’` 无法走 B+树索引，只能全表扫描，数据量上百万就当场社死。

想活命，得换引擎——MySQL 自带的全文索引就是救命稻草，而且 5.7.6之后直接内置 ngram，中文再也不是后妈生的。

倒排索引长啥样？

把“哑光持久不掉色”拆成

哑/光、光/持、持/久……

每个二元组当钥匙，挂一串商品 ID。

搜“哑光”时，直接拿钥匙开门，复杂度从 O(n) 降到 O(log n) 级别，实测 50万行商品表，响应从 4.8 秒压到 0.03 秒，百倍以上提速，真香。

动手四步曲，踩坑版笔记：

1. 建索引

“`sql

ALTER TABLE goods

ADD FULLTEXT INDEX ft_desc (title, description)

WITH PARSER ngram;

“`

ngram_token_size 默认 2，短词狂魔可以调到 1，代价是索引体积膨胀30%，SSD 够硬就任性。

2. 改 SQL

“`sql

SELECT FROM goods

WHERE MATCH(title, description)

AGAINST(‘+哑光 +持久’ IN BOOLEAN MODE)

ORDER BY MATCH(title, description) AGAINST(‘哑光持久’) DESC

LIMIT 20;

“`

`+` 表必须包含，`-` 表必须排除，比 `LIKE` 灵活到飞起。

3. 干掉噪音词

“的”“了”“包邮”这些废词塞进停用词表，索引立刻瘦身15%，搜索质量肉眼可见地干净。

4. 定期 OPTIMIZE TABLE

全文索引是“写时追加，查时合并”，碎片多了性能雪崩。

凌晨低峰跑一把，比白天挨老板骂划算。

有人抬杠：为啥不上 Elasticsearch？

一句话：杀鸡不用牛刀。

ES 的确 更强，但集群、分片、DSL学习曲线陡，中小团队没运维就是灾难。

MySQL 全文索引开箱即用，云数据库直接勾选，省钱省人，90%场景够用。

真实踩坑两则：

• 8.0 之前版本，全文索引列不能是 JSON，升级前记得核对版本。

•高并发写入时，全文索引更新是锁表操作，提议把搜索库独立出去，主从延迟 1秒以内用户无感。

进阶玩法：

把搜索结果当特征喂给推荐模型，用户搜“哑光口红”，系统秒推同色系眼影，转化率再涨7%。

再挂个同义词表，“番茄色=枫叶红=胡萝卜色”，妈妈再也不用担心用户找不到货。

一句话总结：

别让 `LIKE ‘%关键词%’` 继续拖垮业务，全文索引就是 MySQL给你的免费外挂，十分钟改完 SQL，老板 KPI 直接回血。