【MySQL】全文索引（FULLTEXT）的使用

我记得有一次为客户建立了一个电子商务网站。
产品描述很长。
顾客必须搜索一些很长的句子才能找到该商品。
使用LIKE进行的搜索花费了很长的时间并且慢得像蜗牛一样。
后来我们改用全文索引，秒出结果，得到了客户的高度评价。
但这个过程有点棘手。

在MySQL 5 .6 的时候，我们碰巧使用的是InnoDB。
以前我们只能使用MyISAM。
当时我们开玩笑说MyISAM是专门为全文索引设计的存储引擎。
如果创建索引，只需在 phpMyAdmin 中点击几下即可完成，这比手动编写 SQL 容易得多。
检查的时候记得这样写：MATCH(title) AGAINST('Smartphone') 而不是 WHERE title LIKE '%Smartphone%'，这样速度慢而且浪费资源。

最尴尬的就是配置最小搜索长度。
当我更改my.ini时，我将其移动并写为3 结果，我什至找不到“Apple”，不得不重新启动服务器。
当时服务器在机房，当我跑过去重启服务器时，老板以为我在破坏它。
后来发现是这个参数，赶紧改回2 ，然后去机房重启。
这次老板说他学会了。

三种模式中，自然语言模式是最常用的。
我偶尔尝试过布尔模式。
可以用什么+
“”，顾客会搜索“手机+红色
旧型号”，很有趣。
我从来没有接触过查询扩展模式。
有时间我一定要研究一下。
我想知道是否可以自动推荐相关单词。

mysql索引类型有哪些 mysql创建不同索引的方法对比

你说的已经很完整了。

B 树是默认值。
适合解答等式和范围问题。

哈希速度快，但只能等值。
由内存引擎使用。
InnoDB有自适应哈希，不用担心。

全文可在文中搜索。
InnoDB在5 .6 之后可用。

R-Tree 用于地理数据。
相当复杂。

要创建，请使用 CREATE 或 ALTER。
UNIQUE加法是唯一索引。

索引设计必须考虑列选择性。
最初的构建非常有选择性。

综合索引应优先考虑高选择性的索引。
不要重建。

最常见的失败是最左边的前缀没有被使用。
不能使用以 LIKE 开头的。

EXPLAIN 在监控方面非常关键。
查看类型和密钥。

写入会变慢，索引越多越慢。
称重。

就是这样。