典型SQL优化过程

一、现象

Sql执行时好时坏，前端接口和微服务超时，如下图。

 二、分析处置

1、如上图，发现Plan hash value: 1424468760 效率比较低，而Plan hash value: 1532449235效率非常高，具体执行计划如下：

2、按通常来说处置方法很简单，绑定1532449235这个hashvalue的执行计划即可。

开始绑定：

declarem_clob clob;beginselect sql_fullteXtinto m_clobfrom v$sqlwhere sql_id = 'a5ta1sh4rwm3j'and child_number = 0;dbms_output.put_line(m_clob);dbms_output.put_line(dbms_spm.load_plans_from_cursor_cache(sql_id          => 'a5ta1sh4rwm3j',plan_hash_value => 1532449235,sql_text        => m_clob,fixed           => 'YES',enabled         => 'YES'));end;

3、绑定后业务仍然不好用，继续排查发现，该sql绑定变量的数量一直是在变化，导致其产生多个sql_id，虽然是两个相同的sql，因为cust_no变量的数量不同，而导致产生了不同的sql_id具体如下：

Sql_id1：

Sql_id2：

4、统计目前已有100余个sql_id，因此无法通过绑定执行计划解决该问题。

5、查看该表统计信息比较陈旧，收集统计信息，但问题依旧。

6、综合以上分析，在统计信息准确且无法通过绑定计划（sql过多）提高效率，只能修改sql代码加hint的方式开展。参照Plan hash value: 1532449235的执行计划，加hint强制走IDX_QTY_CHARG_LIST_CUST这个索引。具体hint如下图：

至此，问题解决。