前言
这有朋友聊到他们的系统中要接入全文检索，这让我想起了很久以前为一个很古老的项目添加搜索功能的事儿。
一提到全文检索，我们首先就会想到搜索引擎。也就是用一个词、一段文本搜索出匹配的内容。一般这种技术都有对应的实现方式，ES（ElasticSearch）就是专门干这个的，如果你们的业务中明确需要全文检索，或者简单一点说，需要根据关键词搜索出匹配的内容，那就直接用 ES 就好了。
无论你怎么调研，都不推荐使用 MySQL 实现这种需求，显而易见，MySQL 作为关系型数据库，本身就不适合做搜索这种需求。
但是，奈何，今天我们就要用 MySQL 来做这件事儿。
背景
有一个很古老的业务采集了大量的信息，当然是合法采集了。系统用的人已经不多了，并且在平稳地运行，那就不要动它了就好了嘛。可偏偏为数不多的人非要加一个搜索功能，根据一个关键词来搜索。
这项目直接没接触过，咱也不敢随意改呀，通过和少有的还有了解这个系统的同事沟通，发现有一类角色本来就有搜索功能，只不过这功能基本没法用，从来搜不出内容。现象就是点完搜索按钮，后台接口就一直 pending，不用说了，那肯定是因为数据量太大了，或者某种很傻的原因，比如直接在大数据量、大段文本的字段中使用了 like模糊查询。
经过一番查看，发现这个准备要支持搜索的字段是 text类型的， 字段本身是不参与业务计算的，只是用来展示。而要搜索的内容还不止一个字段，好几个字段，这些字段的内容是什么呢，就是一段描述内容，里面有各种各样的专业名词，每一行记录中这个字段最大长度可能有几十到上千个字不等。
这张表由于数据量较大，并且字段很多，所以进行了分表，根据某个上层类型进行拆分，这样分出来的表，大的有上百万，小的有几十万。业务运算的时候，也是固定类型后，在这个类型下的分表中进行增删改查。
一看代码，果然，一条查询好几个 like，在几十万数据量的表中like好几个字段，不慢才怪，能查出来就是奇迹了。
于是勇敢地在数据库中尝试