请把相应执行计划输出，以文本或直接方式，上传看看。

CBO 的威力，成本不同了，Oracle 自动选择成本低的执行计划。

可能和统计信息不够准确有关系

trunc(sysdate)-date'2019-02-28'=20天没更新了

在 Oracle 10g 之中，我建议你将：_b_tree_bitmap_plans 设置为 False。

这是最佳实践推荐设置。

统计信息是准确的，因为是在模拟库生成的，只同步到2019-02-28的数据。@lastwinner

在bitmap上，Oracle是怎么计算成本的呢？@eygle

建议开发个能直接回复 回答者的功能，这样可以方便讨论

120的trc文件可以看到成本最低的是bit map and的执行路径：

1. IDX_ORDER_ORDER_CONFIRM_TIME范围扫描的成本是694.69，索引的选择率是1.4638e-04

Access Path: index (RangeScan)

    Index: IDX_ORDER_ORDER_CONFIRM_TIME

    resc_io: 694.00  resc_cpu: 7033121

    ix_sel: 1.4638e-04  ix_sel_with_filters: 1.4638e-04

    Cost: 694.69  Resp: 694.69  Degree: 1

2. IDX_ORDER_PATIENT_ID范围扫描的成本是15.02

Access Path: index (AllEqRange)

    Index: IDX_ORDER_PATIENT_ID

    resc_io: 15.00  resc_cpu: 165625

    ix_sel: 2.6288e-06  ix_sel_with_filters: 2.6288e-06

    Cost: 15.02  Resp: 15.02  Degree: 1

3. 两个索引bit map and之后的成本是13，优化器选择了cost最低的bit map and执行计划

  Access path: Bitmap index - accepted

    Cost: 13.21 Cost_io: 12.01 Cost_cpu: 12299390 Sel: 3.8236e-10

    Not believed to be index-only

150的trc文件中，成本最低是是IDX_ORDER_PATIENT_ID范围扫描：

1. IDX_ORDER_ORDER_CONFIRM_TIME范围扫描的成本变了，从上面的694.69变为888.88，索引的选择率也从1.4638e-04变为1.8733e-04，

应该就是这里的索引的成本增加，导致bitmap and之后的成本比单独IDX_ORDER_PATIENT_ID范围扫描的成本略高，因此选择了成本最低的IDX_ORDER_PATIENT_ID范围扫描的执行计划

  Access Path: index (RangeScan)

    Index: IDX_ORDER_ORDER_CONFIRM_TIME

    resc_io: 888.00  resc_cpu: 8999327

    ix_sel: 1.8733e-04  ix_sel_with_filters: 1.8733e-04

    Cost: 888.88  Resp: 888.88  Degree: 1

2. IDX_ORDER_PATIENT_ID范围扫描的成本是15.02

  Access Path: index (AllEqRange)

    Index: IDX_ORDER_PATIENT_ID

    resc_io: 15.00  resc_cpu: 165625

    ix_sel: 2.6288e-06  ix_sel_with_filters: 2.6288e-06

    Cost: 15.02  Resp: 15.02  Degree: 1

3. bit map and的成本是15.27

  Access path: Bitmap index - rejected

    Cost: 15.27 Cost_io: 14.01 Cost_cpu: 12906636 Sel: 4.8933e-10

至于为什么两个执行计划不一样，应该和IDX_ORDER_ORDER_CONFIRM_TIME索引选择率变化导致bit map的成本增加有关。

应该和索引选择率有关

谢谢盖总，谢谢各位专家！

非常感谢！