Oracle 12c引入的In-Memory选件通过在同一套数据库中同时维护行式与列式两种数据格式，为分析型查询提供了数量级的加速潜力。传统Oracle数据库以行式存储为核心，适合OLTP事务，但在执行大范围扫描、多表连接和聚合运算时，需要读取大量不必要的数据块，IO和CPU解码开销都较高。In-Memory在SGA中开辟独立的内存列存储区域，将表数据按列压缩存放，并利用CPU的SIMD向量指令进行批量处理，从而大幅减少数据移动和计算指令数。对于报表平台、实时BI看板和混合负载环境，合理配置In-Memory可以显著降低关键查询的响应时间。
In-Memory加速查询的核心机制
要理解In-Memory为什么能加速查询，需要先了解它底层的存储结构差异。普通行式存储将一行记录的所有列连续存放在数据块中，扫描某几列时也必须把整行数据读入内存，即使查询只需要其中一小部分列。In-Memory列存储则把每一列的数据单独组织成压缩单元，称为IMCU（In-Memory Compression Unit）。当SQL只访问少数列时，数据库只需从内存中读取这些列的IMCU，避免读取无关列，降低了内存带宽消耗。
除了列式布局，In-Memory还采用了多种硬件和软件优化。在CPU层面，列式数据天然适合SIMD指令，一条指令可以同时对多个值执行比较、加法等操作，提升过滤和聚合的效率。每个IMCU内部还维护着存储索引，记录该单元中每一列的最小值和最大值。查询执行时，优化器可以根据谓词条件快速判断某个IMCU是否可能包含匹配行，如果范围不符则直接跳过，这就是所谓的存储索引剪枝。对于高频使用的等值过滤和范围扫描，这种剪枝能减少大量无效数据访问。
内存压缩也是重要的一环。In-Memory支持多种压缩级别，从FOR QUERY LOW到FOR CAPACITY HIGH，压缩率越高占用的内存越少，但解压和扫描时的CPU开销也越大。默认的FOR QUERY LOW在压缩率和查询性能之间取得了较好平衡。此外，In-Memory列存储与Buffer Cache相互独立，行式脏块仍按原有机制写入磁盘，列式副本仅作为查询加速结构，事务一致性由Oracle内部维护，不会产生额外的日志负担。
启用与配置In-Memory对象
启用In-Memory的第一步是在实例级别分配内存区域。通过设置初始化参数INMEMORY_SIZE来指定列存储可用的最大内存量，该参数修改后需要重启实例才能生效。例如下面的语句为In-Memory分配20GB空间：
ALTER SYSTEM SET INMEMORY_SIZE=20G SCOPE=SPFILE; -- 重启数据库实例后生效
内存区域分配完成后，还需要在表、分区或物化视图级别启用INMEMORY属性。默认情况下，普通表不会自动填充到列存储。可以使用类似下面的DDL语句将销售事实表标记为In-Memory：
ALTER TABLE sales INMEMORY PRIORITY HIGH COMPRESS FOR QUERY LOW;
其中PRIORITY HIGH表示该表在实例启动后会优先填充到列存储，而COMPRESS FOR QUERY LOW指定压缩级别。如果表数据量很大，填充过程可能持续较长时间，可以查询V$INMEMORY_AREA和V$IM_SEGMENTS视图来监控填充进度和内存占用。对于已经启用In-Memory的分区表，也可以只对热分区启用，冷分区保持行式存储，从而节省内存资源。
需要特别注意的是，In-Memory区域属于SGA的一部分，设置过大会挤占Buffer Cache和共享池的空间，影响OLTP性能。最佳实践是根据活跃的分析型数据规模来估算，通常建议从较小的值开始，观察AWR报告和内存相关等待事件，逐步调整到合理区间。
验证查询是否真正使用In-Memory
仅仅在对象上启用了INMEMORY属性，并不意味着所有相关SQL都会自动利用列存储。Oracle优化器会根据统计信息、谓词复杂度和对象属性来判断是否选择In-Memory访问路径。最直观的验证方式是查看SQL的执行计划。如果执行计划中出现TABLE ACCESS INMEMORY FULL，说明该步骤扫描了In-Memory列存储。可以使用EXPLAIN PLAN或查询V$SQL_PLAN来获取执行计划。
EXPLAIN PLAN FOR SELECT /*+ USE_INMEMORY(sales) */ SUM(amount) FROM sales WHERE sale_date BETWEEN DATE '2023-01-01' AND DATE '2023-12-31'; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
上面的SQL使用了提示USE_INMEMORY强制优化器优先考虑In-Memory访问，便于测试。但生产环境一般不建议添加提示，应让优化器自然选择。如果执行计划显示的是TABLE ACCESS FULL而没有INMEMORY字样，则说明查询没有走列存储，可能原因包括：表尚未完成填充、内存区不足导致部分IMCU被逐出、或者优化器认为全表扫描的代价已经足够低而不需要In-Memory。
此外，动态性能视图V$IM_SEGMENTS可以查看哪些段已经填充到内存，包含每个段占用的字节数、填充状态等信息。结合V$SQL和V$SQL_PLAN，可以分析哪些SQL真正获得了In-Memory加速。在SQL Monitor报告中，还可以看到In-Memory扫描的详细统计，如扫描的IMCU数量、跳过的IMCU数量等，帮助评估存储索引剪枝的效果。
优化技巧与常见误区
In-Memory并非银弹，错误的使用方式可能带来负收益。一个常见误区是认为只要启用In-Memory所有查询都会变快。实际上，对于通过唯一索引或主键进行的单行查找，行式Buffer Cache的延迟往往更低，列存储的扫描优势无法体现。In-Memory主要面向扫描密集型、聚合多、过滤少的分析类SQL，例如星型模型中的事实表扫描、宽表的投影过滤等。
关于填充时机，很多人以为DDL添加INMEMORY属性后数据会立刻可用，但实际填充是在后台异步进行的，大表可能需要数分钟到数小时。如果需要立即完成，可以调用DBMS_INMEMORY.POPULATE过程手动填充特定表或分区。但要注意，频繁的DML会使IMCU失效并需要重新填充，高并发写入场景下维护列存储的成本不容忽视。对于写多读少的表，应谨慎启用。
另一个需要关注的是内存压力与压缩级别的平衡。如果INMEMORY_SIZE设置过小，而需要填充的表数据量很大，Oracle会根据优先级和LRU算法淘汰部分IMCU，导致查询时发生重新扫描磁盘，性能反而下降。可以通过调整压缩级别为FOR CAPACITY HIGH来减少内存占用，但会牺牲部分扫描性能。同时，建议启用自动内存管理相关功能，让Oracle更好地协调各个SGA组件的大小。
最后，In-Memory与并行查询、分区裁剪等技术可以叠加使用，进一步加速复杂查询。例如在一个分区表上，既启用In-Memory，又使用并行度，查询时可以同时扫描多个分区的列存储数据，利用多核CPU并行处理。在设计系统时，应结合业务查询模式、数据更新频率和硬件资源，制定合理的In-Memory应用策略，并定期通过AWR和ASH报告评估实际收益。
Oracle In-Memory查询加速列式存储修改时间：2026-09-25 22:58:02