需要描述：抽凭的抽凭证制单人和审核人的逻辑没有通过子模块的弹性域传递到凭证上的弹性域上，需要穿透到子模块去获取，并且每个子模块的的抽取逻辑还不一样，目前凭证行规模和子分类账规模都是几千万级别，多个表联查效率有点低下，因为改写SQL代价太高，奔着尽量不改动业务逻辑代码的前提下，从代码架构改造和参数配置上来进行优化。
尝试方法：先后尝试了如下方法
SQL TUNING
利用Oracle内置的SQL 执行计划改写，改写后的执行计划未达到很好的效果
SQL 改写
SQL改写：将抽子分类的多个SQL合并到一个大视图当中，不在分段抽取到临时表中，结果比原来更慢，不可行。
Dbms_Parallel_Execute
Dbms_Parallel_Execute，这个并行多用于实体表，因为基于回话的临时表分解任务时会找不到数据，不可行。
管道函数
管道函数的大致是不用将查询的结果集团进行物化，类似于流媒体技术，传统的联合查询是将结果集进行物化后，再输出结果，而管道函数是一执行就能返回结果，并且可以开并行。
用管道函数技术，建立了针对1中视图建立了对应的的OBJECT、TYPE，结果不如优化前理想。
缓存函数
对于相同的输入参数，缓存函数不必再去执行SQL获取结果，直接缓存返回。
将获取制单人和审核认人的逻辑封装成一个缓存函数，但是对于入参为凭证je_header_id +凭证行 je_line_num 来说，重用率并不高，因此提示效果不明显。
物化视图
物化视图相当于实体表，多用于DB_LINK交互的联查，避免网络等待导致耗时，利用空间换时间。
CREATE MATERIALIZED VIEW xxxx_MV
REFRESH FORCE ON DEMAND
START WITH TO_DATE('23-06-2021 11:04:22', 'DD-MM-YYYY HH24:MI:SS') NEXT SYSDATE+5/(24*60) --每五分钟刷新一次
AS
--select 逻辑
使用物化视图需要注意两个刷新方式，一个是全量刷新，这个刷新方式不依赖于物化视图日志表，另一个是增量刷新，这个需要对每个物化视图设计到的实体表建立一个日志表。这两种方式对数据库性能有影响。这个有一定效果，但是数据实时性有延迟，延迟时间依赖于物化视图的刷新时间。
最终使用方式
物化视图 + 函数缓存 + SQL改写 +（merge对比）
将抽子分类的账的所有查询逻辑封装到一个物化视图当中、将该物化视图用job定时的方式来全量刷新。
对于刷新间隔这段时间产生的数据通过用merge对比的方式来将新数据补录。
使用这两个方式后，时间得到大幅度提升，能将原来一个多小时的请求缩短到十几分钟左右，通过DBMS_HPROF进行代码层次化分析有发现在SELECT 中调用的标准功能函数（通过CCID）获取COA段中文描述的函数比较耗时，于是针对这一块做了一个客户化的函数，其实质是做了一个有缓存功能的壳子，这样对于相同的CCID就不用执行sql查询了，直接从缓存返回数据，大大节省了时间，将原来耗时12分钟的sql，改用包了一层带缓存功能的壳子函数后，能提升到2分钟内，节约了10分钟的时间。
综合改造后原来一个多小时的SQL现在运行两分钟就能出结果
总结
之前面试做ETL数据开发的候选人，有时会问到怎么优化，大部分候选人都两个答案：看SQL执行计划+索引改造。
SQL性能优化不是一蹴而就的过程，需要综合结合业务来改造，例如能否改写SQL、当下硬件性能能支持多大的并行、是否能以空间换时间等。