背景：
关于这个标题想了试了好几个总觉得欠那么点意思。大致情况是，在某服务支持中，1张大表4.5T左右，该表也是分区表。其中一个执行频繁的SQL写法有很大问题，导致巨表全量扫描，造成IO负载很大，业务收到严重影响。
由于线上阶段基本上没有改SQL的可能， 只能通过其他途径优化。现场想到一种可行的方案，周末实在手痒，决定测试测试该方案理论上的可行性。
基本情况：
数据库：Oracle 11G
表情况：4.5T左右，二级分区表，3.9万分区，分区如果有数据的话，数据量不大大概是2-3G左右。
分区字段：数据日期+XXX字段。
分区:range-range(应该是range-range这边有点模糊)
SQL情况
SQL比较长，也有好多张表关联，这边只重点说出现性能瓶颈的地方，
SQL：where trunc(分区字段)=trunc(XX, yyyy-mm-dd) and XX like :B ;
导致识别不了分区，只能全分区扫描。
本机测试
表：par_range_range
分区类型:range-range;
分区字段:data_dt (DATE类型); hash_flag (number类型)
SQL：模拟生产环境出现的问题
select count(1) from par_range_range t
where hash_flag <1.5 and hash_flag>=0.1
andtrunc(data_dt) = trunc(to_date('2020-11-01', 'yyyy-mm-dd'));
问题就是 trunc(data_dt) 无法识别那个分区只能走全分区扫描，有经验的人立马知道怎么搞，实际中把搞成 trunc(to_date('2020-11-01', 'yyyy-mm-dd'))<= data_dt < to_date('2020-11-02','yyyy-mm-dd')。现场调整后也是秒杀的，但是甲方需要不改SQL，就能优化。
实验课题：
通过建立索引优化该SQL,(该问题引发一系列思考)
探索巨表建立索引方案(其实这里更感兴趣)
通过建立合适索引把全表扫描转换成索引扫描
巨表怎么建立索引？保证不会占用太多系统资源，比如IO，内存，temp. 甚 至做到系统无感知。因为已经出现了扫描巨表数据时候IO超负载。
前两个可行基础上加快建索引速度
这怎么看都是一个不可能完成的任务。
这里说下最终方案：
建立需要分区索引，建索引时候也要讲究，最初建索引的语句要带上unusable 关键字，这样建索引时候就不会创建索引段，自然也不会扫描表数据。所以这边建立索引能很快完成。
随即按照分区，重建分区索引。因为这边只需要扫描单个表分区，就能很快完成对应分区索引的重建，毕竟扫描数据量小了很多。因此整体方案理论上可行。
数据量：445万，722M ，本机测试环境，数据量有限。这边测试原理
建立索引语句：
create index idx_prr_dt_flag on
par_range_range(trunc(data_dt),hash_flag) local unusable;
测试环境中很快完成。
建立后查询索引分区：
重建分区索引。
重建完成后，这边只查询到重建的索引分区的segement。说明符合预期，只有在rebulid时候才创建索引segement。
优化效果(重建完所有分区后)：
优化前：全表扫描 4.3万逻辑读/次，
优化后：索引范围扫描，414万逻辑读/次 效率提升了近100倍
总结：
该方案精彩的地方在于把复杂的大表建立索引，成功转换成更加细微力度的建立分区索引,解决了大表建立索引过程中带来的IO，内存等系统资源占用率超大等问题。而重建分区索引，单个分区的数据量要小得多，当然重建也容易的多。最终把问题SQl成功优化。
结束语：
本文就是利用延迟加载，完成超大表建立索引，然后再实践中总结知识点。用论语中一句话结尾吧。论语：知之为知之，不知为不知。我在想是不是可以这样“探索”，知之，为，知之！，不知为，不知。可以这样解读：掌握一门知识，并且赋予实践。然后在实践中再总结知识。不了解或者不掌握一门知识，直接干，最终是不能总结出知识的。
