开发环境,碰见一个谓词越界的问题,模拟这条SQL,如下所示,其中A_ID是表test的外键,并且存在索引,
这张表的数据量,大约10万,
查看select 1这条SQL的10053,
看见提示,#2这列,即A_ID,对于超出范围的、不存在的值,使用0.000002作为选择率,即这种选择率,是预估的值,不是实际计算的,换句话说,有可能对执行成本的计算,产生偏差,
Using prorated density: 0.000002 of col #2 as selectvity of out-of-range/non-existent value pred
我们从这张表,A_ID字段实际的存储,看下是否存在他所说的,“超出范围”,
上述结果展示,A_ID的取值范围是6006992-6052756,而trace中,标记A_ID的min和max则是5586857-5726449,因此,这条SQL,出现了传说中的“谓词越界”,
Min: 5586857 Max: 5726449
trace中的min和max,怎么得来的?他是读取的dba_tab_col_statistics视图,通过换算得到的,
但是庆幸的是,虽然出现了谓词越界的问题,并没有因为成本值计算偏差,导致CBO选择错误的执行计划,我觉得和这条SQL的谓词条件比较简单,有一定的关系,可选择的执行计划就这两种,
因此这个案例中,虽然出现了“谓词越界”,对COST的计算,会有误差,但并未影响执行计划的选择,如果是一条谓词复杂的SQL,包含多种执行计划的可能,出现“谓词越界”,选错执行计划,形成性能问题,就是大概率了。
解决方法,就是重采集统计信息,以让COST的计算,更接近实际,避免使用默认值,让CBO作出正确选择。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/7192724/viewspace-2286274/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/7192724/viewspace-2286274/