分析下来，这不是用Redis能解决的缓存问题，而是历史数据的查询响应速度问题。
大家最开始是希望能够通过增加索引的方式解决，但是面对千万级别的数据量，大家也不敢贸然加索引，因为一旦数据库hang住，期间的所有数据库写入请求都会被放到等待队列中，如果请求是通过http请求发过来的，很有可能导致服务发生分钟级别的超时不响应。
虽然经常被用户投诉反应慢，也不能破罐破摔，直接超时不响应了吧。
于是大家陷入了两难的境地。
后来大家分了两个部分来优化持久层。
MySQL的主从配置
第一步就是配置MySQL的主从库，通过将读写请求分离，来提高数据库的响应速度。
从上图可知，来自同一台服务器的请求，经过MySQL-proxy被分流给了不同的MySQL节点，其中写请求给了主节点，读请求给了从节点。因此，大家首先通过分流的方式，减轻了单节点MySQL的响应压力，实现了优化的第一步。
引入ElasticSearch
但是，只配置MySQL的主从是远远不够的。
通过查阅论坛，相关资料，大家最终敲定在持久层引入ElasticSearch。
Elastic Search是一个轻量级的持久层工具，它支持动态多节点部署，自动备份，节点掉线后能够自动切换主从，动态广播发现新上线的节点，而这些优点的应用，无须修改任何server端配置。可以这样理解，如果你部署了4个elastic search节点，其中2个掉了，服务器还是可以很好的继续运行。
此外，它还有一个最重要的优势，那就是支持大数据快速查询。一张几千万的表，如果用MySQL查询，可能需要几秒到几十秒不等，但是如果用elastic search，只需要毫秒级别就能查询到结果。完美的解决了大家当前的问题，还顺带帮大家巩固了持久层的稳定性问题。
综上，优化Mysql的目的是为持久层服务，除了引入主从配置，当MySQL自身局限性导致无法继续优化后，引入其他技术也是十分必要的。
如果你对这篇回答有任何问题，欢迎在下方点赞，留言。
偶是苏苏思量，来自BAT的java开发工程师，头像是本人，每天都会分享科技类见闻，欢迎关注偶，与偶共同进步。
