1.1 字符类型在索引中是“乱序”的，这是因为字符类型的排序方式与我们的预期不同
1.2 字符类型还导致了聚簇因子很大，原因是插入顺序与排序顺序不同。详细点说，就是按照数字类型插入（1..3200000），按字符类型（'1'...'32000000'）t排序。
1.3 在对字符类型使用大于运算符时，会导致优化器认为需要扫描索引大部分数据且聚簇因子很大，最终导致弃用索引扫描而改用全表扫描方式。
解决方案: 将SQL语句由开放区间扫描（>=），修改为封闭区间（between xxx and max_value）。使得数据在索引局部顺序是“对的”。如果采用这种方式仍然走索引扫描，还可以进一步细化分段或者采用“逐条提取+批绑定”的方法。
2.1 对于非标准的日期格式，Oracle在复杂逻辑判断的情况下分区裁剪特性无法识别，不起作用。这种情况下，会走全表扫描，结果是正确的，但是执行效率会很低。通过使用union all，简化了条件判断。使得Oracle在非保准日期格式下也能使用分区裁剪特性，但最佳修改方式还是规范SQL的写法。