Inmemory是Oracle12C开始推出的一个功能。我们一般OLTP数据库中数据是按照行的形式存储的，因为我们新增记录都是insert into，这是一行行的写入。而我们在分析的时候一般都是对一列或者几列聚合统计，count，max，min，avg等等，这些统计的时候对于OLTP数据库其实是一行行的读一次，最后得出的（max和min有索引不会这样）。所以如果一个表列越多，那么做起来就越慢，因为count1列和count100列的值是一样的，所以大部分列做的是无用功。所以从前数据库上做报表效率不高，也就是为什么我们从前会提读写分离，甚至觉得关系数据库处理这个不行，改用hadoop来处理。
但是有了inmemory这种列式存储，这样就解决了这个问题。它的特点是把磁盘上的行存储数据，在内存中以列的形式又存了一份。这样当运行一般的索引查询时候，操作的是行（可能是硬盘也可能是内存），如果运行聚合查询的时候（那么查询的都是内存的列式数据表，这个前提是把这个表做了一下加载到inmemory的动作。就像把hive的数据加载到impala一样其实hadoop也没快，主要是靠机器多机器好。）
这个效果有多大？我用一次问题来说明，日常看到我们很多场景运行一天上亿次的SQL，对数据库几乎没什么冲击（哪怕他是全表），单次执行都是在微秒级别。有一天我被通知说测试数据库访问不到了，我去看看，意外被关闭了。测试环境手工启动一下就行。数据库虽然脆弱，但是只要硬件不坏，基本来说自愈能力还是很强的，这也就是我一直觉得备份意义不大的原因。当然我不是说一点都不要，只是价值不大。数据库一般情况意外可以自己恢复，实在不行，可以依靠高可用。指望备份的话真的是职业生涯的终止了。备份就像我们的保险一样，都要买，但是希望这辈子一次都用不到。因为遇到用保险的话，基本也是大问题了。我们每个人最大的希望就是保险一点作用都没起，这个钱白花了，这是最好的结果。对不对？
好了回过来说重启以后我也没在意，第二天有人说这个数据库比较卡。我们检查了CPU、IO以及OGG等相关。发现就是CPU不高、IO大，会话数多，应用程序连接数据库都成问题。在经过一些列查询之后，从AWR中看到SQL执行的都不快，就是之前说的那种全表关联查询而且频次很高的那种。看了一下执行计划是全表扫描table access full，可是这个是已经加载到inmemory，应该是table access inmemory full才对啊。猛然想到昨晚重启后可能丢失了。于是马上把这些表全部加载一下。效果是立竿见影。开发反馈所有问题全部没有了。
问题解决了，我查找资料看看这个能不能设置成重启以后不丢失。答案是可以的。只要这个操作就可以了。
引申思考。
1、inmemory之前我一直信任他count 一亿可以秒出，甚至不到一秒。（因为列式存储，而且还是内存计算）但是没有想到的是他对于多表关联（目前是2表关联）的提升也是50到100倍的提升，这是我没有想到的。
2、HATP的确对我们真的很重要，避免了读写分离和架构的复杂
3、工信部定义七大未来数据库的第一是多模，第二个就是HATP。MySQL用了heatwave实现，tidb用了tiflash实现，等等大家都在这个方面做足了文章，就是用列式存储来解决关系型数据库上OLTP和OLAP的融合问题。
4、HATP有利于在线数据库上进行大数据场景应用。hadoop会过时或者说已经过时，但是大数据不会过时。
