数据库中谓词越界问题分析
这篇文章主要介绍“数据库中谓词越界问题分析”,在日常操作中,相信很多人在数据库中谓词越界问题分析问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”数据库中谓词越界问题分析”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
开发环境,碰见一个谓词越界的问题,模拟这条SQL,如下所示,其中A_ID是表test的外键,并且存在索引,
SELECT1FROMtestWHEREA_ID=6052138ANDIS_VALID=1
这张表的数据量,大约10万,
SQL>selectcount(*)fromtest;COUNT(*)----------99044
查看select 1这条SQL的10053,
***************************************BASESTATISTICALINFORMATION***********************TableStats::Table:TESTAlias:TEST#Rows:265702#Blks:13157AvgRowLen:180.00ChainCnt:0.00IndexStats::Index:IDX_TEST_01Col#:2LVLS:2#LB:1777#DK:119696LB/K:1.00DB/K:1.00CLUF:118505.00Index:IDX_TEST_02Col#:3LVLS:2#LB:2339#DK:381LB/K:6.00DB/K:272.00CLUF:103794.00Index:IDX_TEST_03Col#:7LVLS:2#LB:786#DK:2292LB/K:1.00DB/K:36.00CLUF:82804.00Index:PK_TEST_IDCol#:1LVLS:2#LB:1652#DK:265702LB/K:1.00DB/K:1.00CLUF:238444.00AccesspathanalysisforTEST***************************************SINGLETABLEACCESSPATHSingleTableCardinalityEstimationforTEST[TEST]Column(#2):A_ID(AvgLen:6NDV:119696Nulls:0Density:0.000008Min:5586857Max:5726449Column(#60):IS_VALID(AvgLen:3NDV:1Nulls:0Density:0.000002Min:1Max:1Histogram:Freq#Bkts:1UncompBkts:10049EndPtVals:1Usingprorateddensity:0.000002ofcol#2asselectvityofout-of-range/non-existentvaluepredTable:TESTAlias:TESTCard:Original:265702.000000Rounded:1Computed:0.50NonAdjusted:0.50AccessPath:TableScanCost:3577.48Resp:3577.48Degree:0Cost_io:3565.00Cost_cpu:460365831Resp_io:3565.00Resp_cpu:460365831Usingprorateddensity:0.000002ofcol#2asselectvityofout-of-range/non-existentvaluepredAccessPath:index(AllEqRange)Index:IDX_TEST_01resc_io:4.00resc_cpu:30301ix_sel:0.000002ix_sel_with_filters:0.000002Cost:4.00Resp:4.00Degree:1Best::AccessPath:IndexRangeIndex:IDX_TEST_01Cost:4.00Degree:1Resp:4.00Card:0.50Bytes:0***************************************...CBRID:TEST@SEL$1TableLookupallocation-Failure-:disabledbyparameter
看见提示,#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字段实际的存储,看下是否存在他所说的,“超出范围”,
SQL>selectmin(A_ID),max(A_ID)fromTEST;MIN(A_ID)MAX(A_ID)------------------60069926052756
上述结果展示,A_ID的取值范围是6006992-6052756,而trace中,标记A_ID的min和max则是5586857-5726449,因此,这条SQL,出现了传说中的“谓词越界”,
Min: 5586857 Max: 5726449
trace中的min和max,怎么得来的?他是读取的dba_tab_col_statistics视图,通过换算得到的,
SQL>selecttable_name,column_name,utl_raw.cast_to_number(low_value)low,2utl_raw.cast_to_number(high_value)hight3fromdba_tab_col_statistics4WHEREtable_name='TEST'ANDcolumn_name='A_ID'5andowner='BISAL';TABLE_NAMECOLUMN_NAMELOWHIGHT-------------------------------------------------------------------------TESTA_ID55868575726449
但是庆幸的是,虽然出现了谓词越界的问题,并没有因为成本值计算偏差,导致CBO选择错误的执行计划,我觉得和这条SQL的谓词条件比较简单,有一定的关系,可选择的执行计划就这两种,
SELECT/*+gather_plan_statistics*/1FROMtestWHEREA_ID=6052138ANDIS_VALID=1select*fromtable(dbms_xplan.display_cursor(null,null,'ALLSTATSLAST'));Planhashvalue:1000423460-----------------------------------------------------------------------------------------------------------------|Id|Operation|Name|Starts|E-Rows|A-Rows|A-Time|Buffers|-----------------------------------------------------------------------------------------------------------------|0|SELECTSTATEMENT||1||2|00:00:00.01|6||*1|TABLEACCESSBYINDEXROWID|TEST|1|1|2|00:00:00.01|6||*2|INDEXRANGESCAN|IDX_TEST_01|1|1|2|00:00:00.01|4|-----------------------------------------------------------------------------------------------------------------PredicateInformation(identifiedbyoperationid):---------------------------------------------------1-filter("IS_VALID"=1)2-access("A_ID"=6052138)
因此这个案例中,虽然出现了“谓词越界”,对COST的计算,会有误差,但并未影响执行计划的选择,如果是一条谓词复杂的SQL,包含多种执行计划的可能,出现“谓词越界”,选错执行计划,形成性能问题,就是大概率了。
解决方法,就是重采集统计信息,以让COST的计算,更接近实际,避免使用默认值,让CBO作出正确选择。
到此,关于“数据库中谓词越界问题分析”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注亿速云网站,小编会继续努力为大家带来更多实用的文章!
声明:本站所有文章资源内容,如无特殊说明或标注,均为采集网络资源。如若本站内容侵犯了原著者的合法权益,可联系本站删除。