个人最欣赏MySQL的地方就是他存储引擎的多样性和可扩展性，这样mysql也能拥有多种多样的个性，嘿嘿！
那今天说说内存表的用处吧：
- 说实话mysql的myisam引擎在查询、插入等方面和内存表引擎基本上是不相伯仲的，所以第一个建议还是能用myisam的地方还是选择myisam引擎
- 但是最近遇到一个比较麻烦的问题，一个用来存储信息的维表，需要频繁的查询、插入以及较频繁的更新操作，并且这个维表非常的大，先是采用myisam引擎并进行数据的分表，拆分成1000个小表，性能也是不错。但是随着数据量的增加和并发度的增加，由于这些表上都有大量的索引，当插入的并发度比较大的时候，mysql的对于磁盘的使用骤然升高，造成系统对于磁盘io的等待，异常的高。
- 由于查询的需求，索引有不能drop掉，所以最开始着手于修改mysql的参数，来提高系统的性能（比如delay insert、batch insert等等），但是效果均不是很理想
- 后来考虑到机器的内存尚有结余，最后采用了内存表的方式，解决了这个问题，基本上消除了磁盘io的等待，系统的负载也基本上下降了一倍
但是这种方式还是有不少问题的：
- 内存表一旦mysql重启，将造成数据丢失，还好这个维表对于数据安全性要求不高，可以允许部分数据丢失，补救方式就是每天在系统负载低的时候进行备份
- 内存表删除后，内存的释放问题：
- 最开始遇到一个很纠结的问题，将建立的这1000个内存引擎小表drop后，系统竟然没有回收内存，先是怀疑mysql存在内存泄露，经过几天对mysql内存引擎源代码的阅读，确定不是内存泄露的问题，后来经过查看linux malloc相关文档，才发现是glibc没有将这些内存交还给系统内核，由于分表后这1000个表都相对较小，gblic的free函数并没有立即将内存sbrk给内核（以备以后的再次malloc），造成这部分内存无法被内核回收
- 这样的话会造成mysql的内存占用异常的高，如果这时候有另外一个程序需要大耗内存的话，可能会有风险。（这块还需要详细测试一下）
小结一下咯：
对于mysql的用户，如果对数据表的内容安全性要求不高，而对于数据的查询和插入的并发度都很大，并且磁盘io成为瓶颈的话，可以使用内存引擎试一试了，也许会有不错的效果
