绑定变量窥视功能是数据库的一个特性，自ORACLE9i版本开始引入，默认是开启的。
“绑定变量窥视”表示，查询优化器在第一次调用游标时，会观察用户定义的绑定变量的值，允许优化器来确认过滤条件的选择性，以及是否使用绑定变量代替了常量。之后调用游标时不会出现窥视，且会根据指针共享标准来共享游标，即使随后的调用使用不同的绑定值。
使用绑定变量窥视，第一次解析包含绑定谓词的SQL语句时，优化器将查看绑定变量的值，并使用该值为查询创建执行计划。然后，不管更改的绑定值如何，该计划都将被存储并用于未来的所有执行。如果初始绑定值不能很好地代表将来执行查询时提供的其他值，那么，即使当前访问路径较优，也可能导致未来执行变差，甚至影响某些迭代的查询性能变慢。
上面的特性是由参数"_optim_peek_user_binds"驱动的，如果禁用这个数据库特性，已经执行过的这类值的执行计划将不会发生变化，但还有一个可能性，一个新值能创造一个更优的执行计划。
本次技术分享，就是，绑定变量窥视参数"_optim_peek_user_binds"对SQL执行计划的影响。在不同的场景下，合理设置"_optim_peek_user_binds"参数，具有重大的实践意义。之前，美创某客户核心系统，就出现过由于"_optim_peek_user_binds"参数设置而引发该核心系统SQL执行出现性能问题。
接下来，我们就来具体了解下，如何在不同场景下充分利用绑定变量窥视这一功能。
首先，来创建一张CONTEXT列数据分布倾斜的TEST表。
SQL> drop table test;
SQL> create table test(id number,context varchar2(20));
SQL> declare
2 begin
3 for i in 1..20000 loop
4 insert into test values(i,'peek_binds');
5 end loop;
6 commit;
7 end;
8 /
PL/SQL procedure successfully completed.
SQL> declare
2 begin
3 for i in 20001..20010 loop
4 insert into test values(i,'peek_binds_01');
5 end loop;
6 commit;
7 end;
8 /
PL/SQL procedure successfully completed.
接着，在TEST.CONTEXT列上创建TEST_INDEX普通索引。
SQL> create index test_index on test(context);
索引创建完成之后， 由于TEST.CONTEXT列数据分布比较倾斜，在收集TEST表统计信息的同时，也要收集TEST.CONTEXT字段的柱状图信息，以便优化器产生最优的执行计划。
SQL> exec dbms_stats.gather_table_stats(ownname=>'XUH',tabname=>'TEST',estimate_percent=>100,method_opt => 'for all indexed columns',Degree=>8,Cascade=>TRUE,Granularity=>'ALL');
之前创建的TEST表有20010行数据，其中CONTEXT列peek_binds值20000行、peek_binds_01值10行。理论上，当过滤条件中代入peek_binds值，执行计划走的是全表扫描；代入peek_binds_01时，执行计划走的是索引。
SQL> set lines 299 pages 9999
SQL> set autotrace traceonly
SQL> select * from test where context='peek_binds';
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
|* 1 | TABLE ACCESS FULL| TEST | 20000 | 292K| 17 (0)| 00:00:01 |
------------------------------------------------------------------------------------------
SQL> select * from test where context='peek_binds_01';
------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
|* 2 | INDEX RANGE SCAN | TEST_INDEX | 10 | | 1 (0)| 00:00:01 |
------------------------------------------------------------------------------------------
当然，为了验证如上SQL的执行计划是否为最佳的执行计划，可以通过hint方式，强制同样的SQL语句走不同的执行计划，并比较执行的成本。对比分析之后，不难发现上述SQL语句采用的均是最佳的执行计划。
SQL> select /*+ INDEX(TEST TEST_INDEX)*/ count(*) from test where context='peek_binds';
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------
|*2 | INDEX RANGE SCAN| TEST_INDEX | 20000 |234K| 62 (0)| 00:00:01| --------------------------------------------------------------------------
SQL> select /*+ FULL(TEST)*/ * from test where context='peek_binds_01';
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
|* 1 | TABLE ACCESS FULL| TEST | 10 | 150 | 17 (0)| 00:00:01 |
--------------------------------------------------------------------------
若想对TEST_INDEX索引的使用情况进行监控，可使用如下ALTER命令开启监控。
alter index TEST_INDEX monitoring usage;
select * from v$object_usage;
以上，我们分析了一张基于列数据分布非常倾斜的表，进行数据分布不一致列值的查询，以及相关SQL获取最佳的执行计划。
接下来，进入正题，上面案例中过滤条件均是以常量的方式代入，相关SQL都能按最优的执行计划执行。那么，当以变量的方式将数据分布不一致列值代入时，SQL的执行计划会如何呢？
先检查下隐含参数"_optim_peek_user_binds"的当前值，确认当前值和默认值均为TRUE，也就是说绑定变量窥视特性，在默认情况下是开启的。要想在数据库级别将绑定变量窥视特性关闭，需修改该参数"_optim_peek_user_binds"为FALSE，并重启实例。
SQL> select
2 a.ksppinm name,
3 b.ksppstvl value,
4 b.ksppstdf isdefault
5 from
6 sys.x$ksppi a,
7 sys.x$ksppcv b
8 where
9 a.inst_id = userenv('Instance') and
10 b.inst_id = userenv('Instance') and
11 a.indx = b.indx and a.ksppinm ='_optim_peek_user_binds'
12 order by
13 translate(a.ksppinm, ' _', ' ')
14 /
NAME VALUE ISDEFAULT
------------------ ----- ---------
_optim_peek_user_binds TRUE TRUE
现在，来定义一个变量A，并将列值peek_binds传入，检查该SQL语句的执行计划，发现采用的执行计划是全表扫描，跟预期相符。紧接着，将列值peek_binds_01传入，发现采用的执行计划是依然是全表扫描，这种现象完全符合绑定变量窥视参数特性的预期，即在绑定变量窥视参数特性启用期间，以绑定变量方式执行的SQL，第一次执行所产生的执行计划，作为该类SQL后续执行的计划。当出现这种情况，意味着第二条SQL类型语句的执行效率降低、响应时间变长。在某些极端的情况下，势必会造成数据库性能问题。
SQL> set autotrace traceonly
SQL> var A varchar2(20);
SQL> exec :A :='peek_binds';
SQL> select * from test where context=:A;
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
|* 1 | TABLE ACCESS FULL| TEST | 10005 | 146K| 17 (0)| 00:00:01 |
--------------------------------------------------------------------------
SQL> exec :A :='peek_binds_01';
SQL> select * from test where context=:A;
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
|* 1 | TABLE ACCESS FULL| TEST | 10005 | 146K| 17 (0)| 00:00:01 |
--------------------------------------------------------------------------
当然，使用AUTOTRACE跟踪，没有实际真正执行，SQL语句执行计划存在不准确的情况。那么，可以在实际执行多次之后，检查CURSOR中缓存的执行计划来进行确认。发现不论传入何值、不论执行次数，该类SQL语句始终只有一个执行计划。
SQL> select sql_id,address,hash_value,plan_hash_value from v$sql where sql_text like 'select * from test where context=:A';
SQL_ID ADDRESS HASH_VALUE PLAN_HASH_VALUE
------------- ---------------- ---------- ---------------
8avvyuyr2m1w7 000000194F6C2460 2921957255 1357081020
SQL> select * from table(DBMS_XPLAN.DISPLAY_CURSOR('8avvyuyr2m1w7'));
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
|* 1 | TABLE ACCESS FULL| TEST | 20000 | 292K| 17 (0)| 00:00:01 |
--------------------------------------------------------------------------
验证了绑定变量窥视参数特性在某些场景下存在的局限性，那么将绑定变量窥视参数特性关闭掉，又会发生些什么呢？
手动将之前该类型SQL语句的执行计划刷出内存，通过hint方式，将隐含参数"_optim_peek_user_binds"强制为false，传入列值peek_binds_01，并执行该类SQL。发现特性禁用之后，传入新值，产生了新的、更优的执行计划，效率更高、成本更低。这里列了以下三种方式可以清除SQL执行计划，分别是DBMS包、FLUSH命令和GRANT语句等。
SQL> exec dbms_shared_pool.purge('000000194F6C2460,2921957255','C',1);
或者
SQL> alter system flush shared_pool;
或者
SQL> grant select on test to xuh;
SQL> exec :A :='peek_binds_01';
SQL> select /*+opt_param('_optim_peek_user_binds', 'false')*/ * from test where context=:A;
------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
|* 2 | INDEX RANGE SCAN | TEST_INDEX | 10 | | 1 (0)| 00:00:01 |
------------------------------------------------------------------------------------------
总结来说，"_optim_peek_user_binds"，该参数默认为TRUE。这就意味着，第一次以变量的方式执行某类SQL时，会生成第一个执行计划，后续执行该类SQL语句，即使变量的传入值不同，但因变量窥视的作用，依然会沿用第一次SQL语句执行时生成的执行计划，这种特性非常适用于业务表数据分布比较均匀的场景，执行计划比较稳定。但对于数据分布严重倾斜的业务表，固定的执行计划，就有可能降低SQL的执行效率，引起前端响应时间变慢等。在极端情况下，会引发严重的性能问题。
当"_optim_peek_user_binds"参数设置为FALSE。即，将绑定变量窥视参数特性禁用。那么已经执行过的某类值的执行计划将不会发生变化，一旦传入某个新值时，优化器会自动根据被访问对象的统计、直方图等信息，产生它认为效率最高、成本最低的执行计划。也就是说，在特性关闭的情况下，该类SQL语句可能会产生更优的执行计划。
转载自：
https://mp.weixin.qq.com/s?__biz=MzA3MTUzNzcwMg==&mid=2649875512&idx=2&sn=da14abca7b373b50e05f4e06bef809ee&chksm=87294171b05ec8672c20afa3a011294c463027b38b4f97de99b50544c2959dfd76e3105c8461&mpshare=1&scene=1&srcid=0809eJkUs2L5HFWhGTJcV9lQ&sharer_sharetime=1565314308951&sharer_shareid=4ea1bc090eabbee4a82e6650a49c5a55&key=0f0abb20a7092e0c8a0339818d201659f9bb7ae7a7ac977473a567731b6cde5f6d729b9f35b289f1b744c46da7771e76de1a0f71c8ace7d3f7a01759fc4d011f1e5fca871429932c158a685c0dd4104d&ascene=1&uin=MjYzMDM4NzYwNA%3D%3D&devicetype=Windows+10&version=62060833&lang=zh_CN&pass_ticket=HIf2NM7kc6R81B4sqhYSmlRwDgDubQA09ctMMoG%2FChvy%2FaF2%2FyxNyfkVftmfHLLH