已经做了充分测试证实，mysql即使加上ngram全文解析器，采用MATCH AGAINST 全文检索方式，实际上在小数据量和大数据量下都不能很好的提高查询效率
所以 目前我们的项目后端程序员请自查自己的项目代码，统一采用like 方式进行匹配查询。
经过测试，like方式在几十万数据量下，即使没有走索引，但在硬件配置不是太差的情况下，查询速度尚可接受。
反而ngram解析器的查询方式，在小数据量下比不过like模糊查询，其原因很复杂，通过explain可以看到走的是全文索引，但由于innodb是支持事务处理的引擎，所以操作锁的最小单位是 （行）。然后再去拆分 fulltext 的列，进入分词器来查询。其效率不是很高。
而由日本团队开发的mroonga引擎，是以 （库）为单位的独立引擎。他的查询原理是：由于不是innodb（锁行）这样的事务处理引擎，也不是myisam（锁表）。是一个完全独立的引擎，他的算法是继承了sphinx的高效全文检索引擎。所以处理方式完全跟mysql原生的不一样，你可以理解为就是mysql的一个外挂扩展。所以在mroonga采用MATCH AGAINST 全文检索方式在0-20亿之间的数据都可以毫秒级（不超过1秒）就能返回查询结果
特别是中文分词，我们属于 CJK 语言（C中文，J日语，K韩语）中ngram分词实际上是按空格+字符来拆分分词，所以支持效率不高。而日本团队开发的mroonga默认就是为了这样的非ascii码字符分词的。
所以总的来说不要再使用mysql的ngram进行全文匹配查询。
至于如果使用mroonga引擎就必须换为mariadb数据库的办法，是我自己研究得不充分。。实际是mariadb是内置了mroonga引擎，而其实可以独立安装mroonga引擎软件，然后外挂方式接入mysql
也就是，在有必要的情况下（一般数据大于100万，like的查询效率会直线下降，因为不走索引，就完全是CPU在复杂运算了，没有引擎支持的情况下，硬件都有性能极限），实际上不用更换mysql数据库，可以独立安装mroonga，让mysql支持高校的全文匹配查询。（上面已经说了，mroonga是继承于sphinx的，至于这个sphinx为什么这么厉害，实践中，老板已经体验过其速度，感兴趣的也可以自己搜索引擎查询）。
当然mroonga的用法上，由于是独立于innodb引擎的，所以也存在一些不是很友好的地方，比如我们又要支持事物处理，又要高校全文匹配，就需要创建一个基于mroonga引擎的独立表。然后用join关联的方式来查询innodb表的其他字段了。
但实测下来，查询速度在3000万左右，还是0.03秒就能返回结果。
所以总结：目前我们的项目后端程序员请自查自己的项目代码，统一采用like 方式进行匹配查询。
程序员在开发当中的经验总结是很重要的，我们由于不断的项目需求，都需要去互联网上查询相关教程，这是很正常的工作需求，但是百度算法问题，一篇教程点击率越高，其排名就会长期保持在首页。其他行业是符合逻辑的，但技术行业根本不符合这个逻辑。也就是实际上百度的教程资料都是很老的比如2013年的都一直在前面，并且新的资料由于关键词与老教程冲突，导致原创性不高，根本不收录的情况。
所以，技术资料，特别是英文关键词的技术资料，建议多使用google引擎。
还有，很多教程作者的使用场景与我们不同，有可能我们会碰到完全找不到资料的情况，所以建议大家，如果处理了一些BUG，有了经验总结，可以自己创建一个博客网站，来记录这些经验。
我准备空闲时间，开发一套博客系统，后面大家可以使用
关于mroonga引擎，找到一篇台湾作者的记录。https://deepskyfire.com/sub/23.html
解释得非常的详细，我也是hi看了这个教程，才算充分理解了mroonga引擎的来历。
sphinx是通用的高效全文匹配引擎，mroonga继承于它。感兴趣的可以认真看一下这个资料
这篇教程，百度是完全找不到了，你可以拷贝标题，然后百度搜索试试。。。也充分证明，百度适合娱乐搜索，不适合技术搜索
台湾人很多关键词跟我们不一样
硬件：硬体
软件：软体
硬盘：软碟
程序：程式
上面太多内容，看下面不感兴趣，看下面这一句就行了
所以总结：目前我们的项目后端程序员请自查自己的项目代码，统一采用like 方式进行匹配查询.
发出来只是为了百度收录，让需要的人能找到一个搜索入口
这是台湾作者的总结：説實話，我最開始尋找全文搜尋引擎的原因就是需要找一個能花最少力氣修改原始程式碼就能從模糊搜尋遷移的方案。在我測試過幾乎所有的全文搜尋引擎之後，幾乎沒有一款能滿足我的需求。直到我知道了 Mroonga 的存在之後進行了相應的測試，我發現 Mroonga 最合適的用途就是這個，花最少的力氣替代LIKE模糊搜尋。
當然我并不是說其他的全文搜尋引擎不好，只是不合適這個需求。
誠然，我承認 Mroonga 的效能在所有全文搜尋引擎裏并不是最好的，但我要求本來也不高，只要能比 MySQL 原生的模糊搜尋快就行了。事實上 Mroonga 也勝任了這點。
Mroonga力求不過多改變MySQL的使用體驗應該說是他最大的亮點。
所以儅你有類似的需求的時候，不妨來考慮一下 Mroonga。
热议
3楼 kaleok 昨天16:10
搜索功能用MySQL，还统一采用like方式进行匹配查询，，，就离谱，，，，，，
专业的事情还是交给专业的工具 ...
我不想跟你争论，你不懂项目开发，发出来只是有需要的人能找到一个解决方案，百度是完全没有相关资料的
4楼 yc260982 昨天16:24
ngram这种太笨了，不如上靠谱的分词，大数据还是得用搜索引擎
5楼 yrj 昨天17:47
感谢分享，看起来不错的样子，可惜中文文章太少，不知道内存占用怎么样。有什么副作用没有
6楼 李嘉诚 昨天17:51
我不想跟你争论，你不懂项目开发，发出来只是有需要的人能找到一个解决方案，百度是完全没有相关资料的 ...
7楼 李嘉诚 昨天17:53
搜索功能用MySQL，还统一采用like方式进行匹配查询，，，就离谱，，，，，，
专业的事情还是交给专业的工具 ...
有白女票的机 给ElasticSearch 吗？
8楼 Westitan 昨天18:50
在用ElasticSearch，省事专业
9楼 天河 昨天19:05
sphinx不香吗？
10楼 ouou8 昨天19:46
支持你一下子
12楼 flyqie 3小时前
感谢楼主的分享，很有用，谢谢！
13楼 POMAH 半小时前
感谢分享，学习了。
14楼 hizhi 21分钟前
支持下，好的经验
15楼 求道鱼 5分钟前
前几天把爬虫站从xiuno 转到 Flarum，也是为这个中文搜索烦恼了一番，找了半天只看到了 ngram 方案，我还特意从MariaDB 10.5.5 切换到MySQL 5.7
申明：本文内容由网友收集分享，仅供学习参考使用。如文中内容侵犯到您的利益，请在文章下方留言，本站会第一时间进行处理。