这篇文章主要介绍“数据库中谓词越界问题分析”，在日常操作中，相信很多人在数据库中谓词越界问题分析问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”数据库中谓词越界问题分析”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

开发环境，碰见一个谓词越界的问题，模拟这条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作出正确选择。

到此，关于“数据库中谓词越界问题分析”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！