Mysql内存表的用处, 2010年的帖子

2016/09/25 23:28
阅读数 164

个人最欣赏MySQL的地方就是他存储引擎的多样性和可扩展性,这样mysql也能拥有多种多样的个性,嘿嘿!

那今天说说内存表的用处吧:

  1. 说实话mysql的myisam引擎在查询、插入等方面和内存表引擎基本上是不相伯仲的,所以第一个建议还是能用myisam的地方还是选择myisam引擎
  2. 但是最近遇到一个比较麻烦的问题,一个用来存储信息的维表,需要频繁的查询、插入以及较频繁的更新操作,并且这个维表非常的大,先是采用myisam引擎并进行数据的分表,拆分成1000个小表,性能也是不错。但是随着数据量的增加和并发度的增加,由于这些表上都有大量的索引,当插入的并发度比较大的时候,mysql的对于磁盘的使用骤然升高,造成系统对于磁盘io的等待,异常的高。
  3. 由于查询的需求,索引有不能drop掉,所以最开始着手于修改mysql的参数,来提高系统的性能(比如delay insert、batch insert等等),但是效果均不是很理想
  4. 后来考虑到机器的内存尚有结余,最后采用了内存表的方式,解决了这个问题,基本上消除了磁盘io的等待,系统的负载也基本上下降了一倍

但是这种方式还是有不少问题的:

  1. 内存表一旦mysql重启,将造成数据丢失,还好这个维表对于数据安全性要求不高,可以允许部分数据丢失,补救方式就是每天在系统负载低的时候进行备份
  2. 内存表删除后,内存的释放问题:
    1. 最开始遇到一个很纠结的问题,将建立的这1000个内存引擎小表drop后,系统竟然没有回收内存,先是怀疑mysql存在内存泄露,经过几天对mysql内存引擎源代码的阅读,确定不是内存泄露的问题,后来经过查看linux malloc相关文档,才发现是glibc没有将这些内存交还给系统内核,由于分表后这1000个表都相对较小,gblic的free函数并没有立即将内存sbrk给内核(以备以后的再次malloc),造成这部分内存无法被内核回收
    2. 这样的话会造成mysql的内存占用异常的高,如果这时候有另外一个程序需要大耗内存的话,可能会有风险。(这块还需要详细测试一下)

小结一下咯:

对于mysql的用户,如果对数据表的内容安全性要求不高,而对于数据的查询和插入的并发度都很大,并且磁盘io成为瓶颈的话,可以使用内存引擎试一试了,也许会有不错的效果

展开阅读全文
加载中

作者的其它热门文章

打赏
0
1 收藏
分享
打赏
1 评论
1 收藏
0
分享
返回顶部
顶部