在我们的数据库达到性能瓶颈之后，自然而然会想到分库分表。但分库分表之后，又带来了其他一些问题，比如如何联表查询、如何分页查询，大部分场景还是停留在查询层面。前几期也分析了一些常规的处理方法，像增加冗余字段和重构查询表等等。然而，这些本质上还是基于数据库层面，还是要依赖数据库的性能。过分依赖数据库，其实是存在一些问题的。
在大部分场景下，尤其是高并发的情况下，单纯依靠数据库的性能，可能就不太行了，除非有足够的资金进行横向扩充。对于大多数公司来说，这并不可取。那有没有其他方法能够提升整个系统的查询性能呢？
我们在前面几期系统地讲过 Redis，在查询场景中，Redis 必不可少。对于一些静态或者变动不大的数据，比如商品数据，可以直接扔在 Redis 里面。还有像购物车这种临时的数据，付款之后就会删除，也可以存在数据库里。像点赞、收藏这种操作频繁的数据，由于数据基于内存，所以在查询性能上，要比传统的数据库查询高好几个数量级。
同样基于内存的还有 ES，也有同学提出，在分库分表之后，可以异构一份数据到 ES 中，这样就不用考虑复杂的分页，这确实是个不错的方案。
其实说到 ES 呢，核心有两点。一是 ES 的倒排索引，每一个数据、每一个字段都进行了分词，每一个分词都会建立索引。这样在检索关键词的时候，就可以通过关键词直接找到倒排索引的位置，然后按图索骥。反观 MySQL，如果是模糊查询，很多时候索引就失效了。
二是 ES 基于内存的特性，ES 把数据处理并建立索引后，会全部扔到内存里面。在这一点上，ES 要优于 MySQL 的 B+树结构。MySQL 需要将索引放在磁盘，每次读取需要先从磁盘读取索引，然后再寻找对应的数据节点。而 ES 却能够直接从内存里面找到目标文档对应的大概位置，大大提升了查询效率。而且 ES 支持 PB 级的数据存储，支持分布式部署和横向扩展，只要内存足够多，异构一份数据到 ES 中，这个方案是可行的，包括分页查询和列表查询也都能支持。
