盘点MySQL缓存优化方案🎯🎯
前言
最近迭代的产品版本从2.X来到了3.X，属于一个非常大的产品升级，比上个版本多了很多功能。那么上线之前肯定要在一个干净的环境里进行测试回归以及性能测试。
刚开始部署的时候系统风调雨顺，可是后续运行了半个多月吧，查询的性能整体下降，今天盘一下数据库层面的一些缓存机制对查询速度整体的优化。
查询缓存
想必大家应该都知道这个相对比较鸡肋的querycahce机制，从诞生以来就不怎么受人待见，在mysql5.6将该机制默认关闭，到了mysql8直接将他取消了。
查询缓存顾名思义是将查询的结果集缓存住，可以简单理解为整个sql为key，缓存sql的结果，每一次select查询都会先检查querycache是否有缓存，如果存在缓存的数据则直接返回，相比于磁盘读取性能提升n倍。
听起来十分合理，但缺点也十分明显：
- 基于sql来缓存严格到字节级别，只要sql中多一个空格就不会走缓存。对于线上环境比较生硬。
- 只适用于读多远大于写少的场景，一有ddl预计缓存就会失效。
- 打开查询缓存后如果一条sql没有命中会消耗额外的资源把结果集维护起来，浪费资源
所以一般的线上环境都不推荐使用这个机制。
表缓存
如果大家有背过mysql的八股文一定对innodb_buffer_pool_size这个参数不陌生，既然叫innodb_buffer说明这是innodb引擎特有的参数，负责缓存磁盘中的数据减少磁盘IO提升读写速度。
由于innodb读取数据的基本单位是页并且使用B+树索引结构来组织数据，每个索引页通常包含多个数据行，数据行按照主键的顺序进行排序。通过主键索引，可以快速定位到目标数据行所在的索引页，然后读取对应的磁盘页。
每次读取数据会连带着整条数据页被加载，好不容易消耗了资源读磁盘拿出来的数据不能浪费，理所当然的存在了buffer_pool里，比如第一次查询select * from A where id = 1，在1附近的数据都被缓存到了buffer_pool中，下一次执行select * from A where id = 2时就会从缓冲池里拿。
并且buffer_pool通过change_buffer来记录增删改对数据的变更操作，这样就会极大的优化查询速度并节省性能，缓存失效也会根据LRU的机制去淘汰旧缓存。
从这次产品迭代升级的新环境中发现，部署一个新的mysql容器可以注意调整一下innodb_buffer_pool_size对应的值，默认为128M，通过以下命令查看。
show variables like '%innodb_buffer_pool_size%';
一般我们可以调整为机器内存的1/4，这个可以视情况而定，修改完之后会发现性能提升一大截。
ReadySet
先放一下官方文档:
上面的都是MySQL自带的缓存方案，这个组件是最近逛github的时候碰巧看到的中间件，一个高性能且轻量的mysql&pg数据库缓存解决方案，无需额外代码即可将最复杂的 SQL 读取转变为闪电般快速的查找。本质上基于jdbc实现了一套服务，对上层而言就是一个数据库，
由于我也是刚接触不是特别了解只能简单聊一下，它本质上是用一个数据流图的机制去做的，所谓数据流图按我理解就是一个快照，基于用户的sql构建一个快照，后续的增删改语句与buffer pool思路一样，在内存中计算。
这个方案思路上有点类似mysql中的查询缓存和buffer_pool的整合版本，也是通过sql去缓存数据，需要主动通过使用CREATE CACHE FROMSQL扩展，将查询缓存在ReadySet中，通过SHOW CACHES查看所有缓存SQL，然后缓存的数据本质上是构造了快照，有数据更新会监听binlog同步到快中中并支持最终一致性保持缓存一致，当然会有一点点的数据延迟。
所以这类中间件用着用着就会带来巨大的内存开销，不过在BI类似的平台中可以试一试。