为什么 ElasticSearch 比 MySQL 更适合复杂条件搜索？

因为底层数据结构不一样。mysql的索引结构是b+tree,有两种索引，一个基于主键id的，叶子节点有这一行所有字段的值，另一种是基于某一列的，叶子节点存主键id，你要是按照多个字段去搜，他只能用某一个字段的索引，而不能全用上，你看执行计划就可以知道，mysql选择cost最小的字段的索引来搜，其他你搜的字段基本上都是在结果里面一个个过滤，这是最核心的不同es就不一样了，多字段的索引他全可以用上，比如用关键字在倒排索引中查到一堆符合条件的文档id，然后再通过类似status，type之类的term查询得到另一部分文档id，本质上每个查询结果是不同的bitset，最后做位运算求并集就得到了所有id，然后用id再查具体的返回字段值，可以从souce里面查还可以通过store为true的字段里面查. ElasticSearch与MySQL相比，它高效搜索核心是并行计算和倒排索引。 MySQL架构本身不是分布式架构，它的分库分表也只能解决数据存储的问题，解决不了查询问题，比如无法支持复杂查询：任意列的相互组合查询。 #### MySQL索引 要想实现对任意数据库的高效搜索，避免全表扫描，就要建立索引。MySQL可以对单列建立索引，也可以按照一定顺序对多列建立组合索引。但看起来美好，实则还是存在不少问题： > 在生产环境下，查询条件通常不会是单一的。所以单列索引应用场景受限。 MySQL组合索引要求按照顺序，执行的时候严格从左到右匹配执行（索引最左前缀匹配），一旦你的查询条件不符合组合索引列的次序，或者查询条件多变，组合索引就会失去它的高效。 #### ES索引 那ES底层索引又是什么数据结构，为什么它可以做到多个字段的任意组合查询呢？ES底层是Lucene,它的索引是倒排索引。倒排索引实现‘单词-文档ID’的存储形式。通过倒排索引结构，可以快速根据单词获得包含这个单词的文档ID列表。**假如是任意多字段组合的搜索，Lucene就会对多个字段搜索结果进行合并求交集返回。**