Oracle In-Memory列存储开启后SELECT查询成本未下降原因问询

• 执行计划成本估值逻辑未适配InMemory特性
  Oracle的执行计划成本默认基于传统磁盘IO、CPU开销的估算规则，12cR1等早期版本的成本模型没有将InMemory列存储的向量计算、列裁剪、谓词下压等优化收益纳入计算，因此即使执行计划显示走了TABLE ACCESS INMEMORY FULL，展示的成本值仍会沿用全表扫描的旧估算结果，该数值不代表实际运行性能。判断性能差异请对比SQL真实执行的耗时、逻辑读/物理读指标，不要仅参考执行计划预估值。

• 表数据未完成InMemory区域加载
  ALTER TABLE CAR INMEMORY仅为表添加InMemory属性标记，Oracle不会主动立刻加载数据到InMemory列存储区，只有首次访问表时才会触发异步加载。如果执行计划是首次查询生成的，此时数据未完成加载，查询仍会走磁盘读取，自然没有性能提升。
  可执行以下语句验证加载状态：

SELECT TABLE_NAME, INMEMORY_SIZE, BYTES_NOT_POPULATED 
FROM V$IM_SEGMENTS 
WHERE TABLE_NAME = 'CAR';

若BYTES_NOT_POPULATED大于0，说明表还未完全加载到InMemory区域，待加载完成后再执行查询即可看到性能提升。

• InMemory空间配置不足
  需确认CAR表的实际占用空间小于等于你设置的200M InMemory区域大小，若表体积超过200M，Oracle仅能加载部分数据到InMemory，剩余数据仍需走磁盘扫描，无法充分发挥InMemory的优势。同时需确认INMEMORY_QUERY参数已设置为ENABLE，保证会话允许使用InMemory查询能力。

• 当前查询场景下InMemory优势不明显
  你执行的是C_PRICE列的MIN/MAX聚合查询，如果该列上已建立索引，走索引扫描的效率本身就高于全表扫描（包括InMemory全扫描），该场景下InMemory的优化收益无法体现。InMemory更适合多列过滤、大范围多维度聚合、即席查询等传统全表扫描性能瓶颈明显的场景。

内容的提问来源于stack exchange，提问作者Sunny J