Oracle 12c 中的In memory选件通过在SGA中分配独立的内存区域(In Memory Area)，对数据使用列式压缩存储来提高查询性能。
那么，这个In memory特性，到底能对性能有多大提升，我们做了一系列的实验，来看看不同场景下的性能表现。但首先要说的是，采用了In memory特性，性能并不一定提高，后面我会举例子。
In Memory区的大小由参数inmemory_size控制，该参数是一个静态参数, 修改后需要重启数据库方可生效。
修改命令：
SQL> alter system set inmemory_size=2G scope=spfile;
System altered.
重启之后
应用查询测试结果
可以看出，三种查询条件，采用了内存特性之后，响应时间分别提升了23倍、2倍和6倍。
增删改测试结果
不过在某些场景下（比如，单用户大批量插入，后面的案例均采用单用户），插入的速度还是可以提升不少的，如下图。
测试案例中准备了100万笔数据，采用 Insert into Select方式插入两张表，测试结果如下：
某复杂的联合查询，内存表比普通表的查询速度提升20倍。那么，在有其他业务压力干扰下，他的查询性能是怎么样的？
带着这个问题，我们以每秒5000笔的速度向内存表和普通表插入数据。在该压力下测试这个复杂联合查询的性能
复杂SQL：此处略过，写出来有好几行，看不懂
可以看出，在这个压力干扰下（每秒5000笔插入数据的干扰），这个查询性能的提升，从原来的20倍，变成了4.3倍
Oracle有不同的压缩方式，我们先看看有哪些，都是怎么介绍的。
关注一下“MEMCOMPRESS FOR QUERY LOW”，咱们简称QUERY LOW吧，这个是缺省方式，号称查询性能最优。
上面的实验中我们是采用DML的方式的内存表，现在采用QUERY LOW方式试试：
内存表采用QUERY LOW方式后，性能提升变成了3.5倍，似乎还不如DML的提升4.3倍。看来官方文档也只能参考参考，具体您的环境、您的场景是什么参数性能好，那还得去调优。
DML v.s. QUERY LOW方式的性能的确有差异，这种差异的固定的吗？
我们换一个SQL语句，换成一个比较简单的SQL查询看看
在这个简单SQL查询的场景中，QueryLow方式性能提升效果更明显。因此，谁快谁慢it depends。
在两实例均开启In-Memory特性的情况下，跨分区查询的效率竟然不如只在一个实例使用In-Memory特性。
总体来说，In-Memory特性是可以提升大部分查询场景的性能，但增删改场景很可能是混个持平，对于一些特殊场景，竟然还不如不使用In-Memory。不同的压缩方式下，性能的确不同，但有些场景下并不是官方介绍的那个性能结果，如果要得到最佳的性能，还得靠实操性的调优。
