Row Cache For Innodb -- MySQL -- IT技术博客大学习 -- 共学习共进步！

最近在做MySQL的优化,看到现在MySQL分表分库后导致的内存利用率较低的问题,进行了优化,如果你也有类似的问题,可以试试下面的Patch

Patch下载: http://code.google.com/p/row-cache-for-innodb/

问题

当一个MySQL存不下全部的数据时,那么分库分表是一种常规的解决方案.但是一旦分库分表之后,关系型数据库对应的关系实际上被弱化了,很多查询不得不转换为类似K-V的查询.一般情况下为了使分库分表的数据尽量的平均都采用去模(mod)的算法来分配数据,这样就导致热门数据也会很离散的分布在各个表的各个区段上,分布很离散. 而Innodb的Buffer Pool则是按Page(默认为16k大小)来进行缓存,那么可能热门数据只占16k中的2k甚至更少(对于辅助索引来说会更少,可能只有几百个字节),那么被载入到Buffer Pool中的数据会被读取的可能就很少了,也就是说Buffer Pool的内存利用率是很低的.

解决

既然是由于Buffer Pool无差别缓存一个Page导致内存利用率低,那么我们可以直接缓存row来提高内存利用率. 所以Row Cache For Innodb就诞生了. Row_Cache 在Buffer Pool之上再建一层缓存.在innodb访问B-Tree的时候判断索引是唯一索引,且查询条件是唯一查询的时候(就是典型的K-V查询)便会进入到Row Cache的查找逻辑中. 由于只缓存Row内存利用率会很高,即能缓存的热门数据会比Buffer Pool多很多. 按照压测的结果来看240w的热门数据(数据分布较离散) 使用18G的Buffer Pool是无法完全载入到内存的.导致随机select数据还会有大量的IO操作存在QPS维持在一个较低的水平.但是使用Row Cache后240w的数据只使用了5G内存就能全部载入到内存中,QPS能提升几倍

额外收货

Row Cache使用Hash算法+LRU算法进行缓存数据的管理,所以将原来Buffer Pool中的B-Tree查询转化为Hash-Table的查询,使数据能被较快命中,节省了CPU使用也提升了响应时间

Row Cache中的Hash-Table管理采用区段锁而非Buffer Pool的单一全局锁,降低了锁竞争而导致的上下文切换.而且对LRU 和内存池也和Hash-Table区段对应,各个区段独立维护各自的资源

适合的使用场景

查询以K-V形式为主类似 select * from table where key = ? 这样的查询,而且key字段需要建唯一索引

读>写

热门数据较集中,且基本都能放在内存中

Row Cache和handlersocket配合应该是不错的选择

性能测试

使用了淘宝某核心系统对Row Cache的效果进行了性能测试和稳定性测试.

机器配置:

CPU:16核的Xeon(R) E5520 @ 2.27GHz