Oracle 12.1.0.2版本了引入了一个非常牛叉的功能，即In Memory option，这是十分具有诱惑力的，针对这个重大的变化，我会进行一个系列文章的分析，这是第一篇。

首先，我们来尝试下In Memory option功能。

未启用in Memory 特性之前，大家可以看到执行计划是上述这样的，虽然SQL执行过一次了，然而再次执行仍然会有不少的代价，下面我们来看下开启in Memory 特性后的情况。首先我们来了解下in Memory option相关的几个参数：

这里针对in memory option的几个参数进行简单说明：

inmemory_size：该参数可以在cdb或pdb级别进行设置，即In memory column store的内存区域。
inmemory_force：该参数默认值为default，表示Oracle仅仅通过对象的inmemory或no inmemory特殊来决定是否启用in memory column store特性。
inmemory_max_populate_servers：表示后台启动多少个进程来加载数据到memory中。对于多core（多cpu)的系统来讲，可以设置相对大一点。
inmemory_query： 表示In memory query是否被启动，默认为enable。

还有有一个参数：OPTIMIZER_INMEMORY_AWARE，表示Oracle CBO是否参考in memory column store功能。这里Oracle的官方文档描述其实有误。

这个参数在12.1.0.2中其实是一个隐含参数：

从这部分隐含参数，我们其实可以大概看出来12c中的优化器的一些机制。下面再调整下另外一个参数，注意这个参数只能在CDB级别进行调整。

我们可以看到如果你开启了in memory option的话，那么SQL的执行代价确实要少很多，优势比较明显。然而，这里不知道大家
注意到了没有？ 为什么开启了in memory 特性之后，再次执行SQL时，还有一个物理读呢？

对于In memory Option这里有几种属性：

1） IM Column Store Compression Methods
2） IM Column Store Data Population Options

对于In Memory column store compression来讲，又分为几种情况，上面的FOR QUERY LOW 就是默认行为. 根据官方文档的描述分为如下几种：

NO MEMCOMPRESS    ：  即存在In memory内存中的该对象的列数据是不会被压缩的。
MEMCOMPRESS FOR DML： 这种属性的设置下可以优化DML操作以及最小程度的压缩In memory column store的数据。
MEMCOMPRESS FOR QUERY LOW： 这是默认设置，Oracle认为这是最利于查询性能的设置。这种情况下数据的压缩比例是介于FOR DML 和 QUERY HIGH之间的.
MEMCOMPRESS FOR QUERY HIGH: 这种情况下查询性能也是相对较优的，列数据的压缩比例在FOR QUERY LOW 和 FOR CAPACITY LOW 两种默认之间。
MEMCOMPRESS FOR CAPACITY LOW：这种情况下也能获得不错的查询性能，数据压缩情况介于FOR QUERY HIGH和FOR CAPACITY HIGH之间。
MEMCOMPRESS FOR CAPACITY HIGH：这种情况下压缩比例是最高的，通常是不推荐的，没有性能上的优势。

 
对于IM Column Store Data Population Options来讲，这种属性的设置只能是对象级别，分别表级别或分区级别，不能进行column级别的设置。
PRIORITY NONE  :即 不启用对象的PRIORITY特性。什么是PRIORITY呢，其实就是定义对象的活跃程度。
当达到一定的活跃程度之后，该对象会被放到in memory area中。默认情况下oracle不会启用这个属性，即默认为None。

PRIORITY LOW :表示启用priority特性，只是level较低，为low。
PRIORITY MEDIUM :表示启用priority特性，level介于LOW 和High之间. 目前暂时不知道oracle是如何来定义这个low，medium和high的。
PRIORITY HIGH   :表示启用priority特性，level介于MEDIUM 和CRITICAL之间
PRIORITY CRITICAL：表示启用priority特性，level是最高的。

未完待续!