MySQL Memory Engine Test

以前一直不关注memory类型的表,觉得没啥好的,数据放到内存中不安全,而且占内存,hash索引使用的诸多限制...
最近发现公司好多项目都在用memory表,于是就简单测试了下.
1.memory表默认创建index是hash索引,虽然memory也支持btree索引,但需要指定.这里就有个值得注意的地方了,要是在程序中大量使用等值查询一类sql语句,但是如果出现大量的范围查找还是指定btree比较好.
2.innodb表也支持把数据和索引完全加载到内存中,相比之下,memory占用的内存要小于innodb,且memory全表扫描效率略高于innodb,这应该是和innodb独特的类btree数据结构有关.当然并不能说innodb不如memory,只是读方面和全表扫描上,毕竟行级锁和事务的innodb在大规模的写操作和数据安全性上是memory不能比的.
3,当数据量比较多的时候一定要修改max_heap_table_size系统变量,否则会限制插入.即使突破了改变的限制,memory表的大小还是会受到OS内存寻址空间,和物理内存的限制,物理内存好理解,在32位的OS上最大支持4G的内存寻址空间也很好理解.
4.memory不支持text.blob字段类型.使用memory引擎最好不要存太大的数据,实在费内存.memory中char和varchar类型并没有什么区别.
5.挡在MySQL Replication中使用memory的时候,如果master重启而slave没有的话,那么master自启动开始就没有数据,而slave中则依然存在数据.直到该内存在master上第一次被调用的时候,master会在binlog中写入一条deleted from语句来删除数据,所以这个时候,slave中有在master启动到执行第一条sql之间的间隔时间的过期数据.这个可以通过master上配置--init-file选项来解决
附:
A.memory占用内存的官方计算公式

SUM_OVER_ALL_BTREE_KEYS(max_length_of_key + sizeof(char*) * 4)

+ SUM_OVER_ALL_HASH_KEYS(sizeof(char*) * 2)

+ ALIGN(length_of_row+1, sizeof(char*))

B.建表的sql和生成测试数据的sp

root@localhost in zhwq 06:59:15>create table mem(

    ->  id int auto_increment not null primary key,

    ->  num int default 100,

    ->  datetime datetime,

    ->  index mem_num_b (num) using btree,

    ->  index mem_num (num),

    ->  index mem_dt_b (datetime) using btree,

    ->  index mem_dt (datetime))engine=memory character  set utf8;

Query OK, 0 rows affected (0.04 sec)

root@localhost in zhwq 06:59:43>delimiter #

root@localhost in zhwq 07:03:20>create procedure insert_mem(p int)

    -> begin

    ->  set @i = 0;

    ->  repeat

    ->    insert into mem (num,datetime) values(floor(rand()*1000),now());

    ->    set @i = @i+1;

    ->  until @i > p end repeat;

    -> end

    -> #

Query OK, 0 rows affected (0.03 sec)

root@localhost in zhwq 07:20:02>delimiter ;

root@localhost in zhwq 07:20:07>call insert_mem(1000);

Query OK, 0 rows affected (0.05 sec)

有网友测试过memory和memcache之间的性能比对,个人认为两者的场景一般不会相同,可比性不太大,有空再研究下