为什么MySQL不适合大数据文本检索

我们为什么不用MySQL作为大数据文本搜索，而是要选用搜索引擎，跟他们底层采用的结构有关系，接下来我们一起来探索

首先要知道MySQL 架构天生就不适合海量数据查询，它只适合海量数据存储，但无法应对海量数据下各种复杂条件的查询。

有人就说加索引不是可以避免全表扫描，提升查询速度吗，为啥说它不适合海量数据查询呢？

其实是有两个原因：

• 首先就是加索引确实可以提升查询速度，但是在 MySQL 中加多个索引最终在执行 SQL 的时候它只会选择成本最低的那个索引，如果说没有索引满足搜索条件，那么就会触发全表扫描，而且即便你使用了组合索引，也要符合最左前缀原则才能命中索引。

但是在海量数据多种查询条件下很有可能不符合最左前缀原则而导致索引失效，而且我们知道存储都是需要成本的。

如果针对每一种情况都加索引，以 innoDB 为例，每加一个索引，就会创建一颗 B+ 树。

如果是海量数据，将会增加很大的存储成本，之前就有人反馈说他们公司的某个表实际内容的大小才 10G, 而索引大小却有 30G！这是多么巨大的成本！所以千万不要觉得索引建得越多越好。

假如说你搜索 格力空调 有关的东西 是不是这样搜索的 %格力空调%，最左前缀就是这样的 格力空调%，你后面是什么无所谓，关键前面要匹配上

接下来再来说说他的第二个原因

• 有些查询条件是 MySQL 加索引都解决不了的，比如我要查询商品中所有 title 带有「格力空调」的关键词，如果你用 MySQL 写，会写出如下代码：

SELECT * FROM product WHERE title like '%格力空调%'

这样的话无法命中任何索引，会触发全表扫描，而且你不能指望所有人都能输对他想要的商品，是人就会犯错误，我们经常会犯类似把「格力空调」记成「格空调」的错误。

那么 SQL 语句就会变成：

SELECT * FROM product WHERE title like '%格空调%'

这种情况下就算你触发了全表扫描也无法查询到任何商品，综上所述，MySQL 的查询确实能力有限。与其说上面列的这些点是 MySQL 的不足，倒不如说 MySQL 本身就不是为海量数据查询而设计的。所以呢，术业有专攻，海量数据查询还得用专门的搜索引擎，这其中 ES 是其中当之无愧的王者。

那么 ES 中的索引为何如此高效，能在海量数据下达到秒级甚至毫秒级的效果呢？
它采用了多种优化手段，最主要的原因是它采用了一种叫做倒排索引的方式来生成索引，避免了全文档扫描。
那什么是倒排索引，通过文档来查找关键词等数据的我们称为正排索引，返之，通过关键词来查找文档的形式我们称之为倒排索引。

下一篇文章会介绍倒排索引相关的内容