oracle 执行计划里的cost(%CPU)与consistent gets

有一次做实验,产生了以下的疑惑:

oracle 执行计划里的cost(%CPU)与consistent gets之间是什么关系? 为什么会存在consistent gets大,而 Cost 小的情况?


一般不都是cost小,越有利于SQL优化,相应的consistent gets应该小才对。







看了一本优化书 ,解答如下:

真正决定性能的是  cost的高低      真实完成的时间time 

一般COST越小性能越高,oracle执行计划的选择就是由COST来决定的。

在逻辑读方面,在绝大部分情况下,逻辑读越少,性能越快,大多数情况下可以做为调优的依据,但有些场合并不适用。如以上情况,COST值小,但consistent gets值大。

相对来说,COST除了考虑IO,也考虑了CPU等开销。

### Oracle 执行计划耗时分析优化 #### 1. Cost 参数的理解 CostOracle 优化器用于评估 SQL 查询执行路径的一个重要参数。该数值反映了查询操作预计所需的资源量,包括 CPU 和 I/O 成本等[^1]。 #### 2. 使用统计信息进行性能监控 为了更精确地掌握SQL语句的实际运行效率,可以采用 `STATISTICS_LEVEL=ALL` 或者 AUTOTRACE 工具来收集详细的执行统计数据。前者允许开发者观察缓冲区命中次数(BUFFERS)同返回记录数量之间的比例关系;后者则提供了关于一致性读取次数(Consistent Gets)相对于处理过的行数的数据比率情况[^2]。 #### 3. 关键参数解释及其影响因素 除了上述提到的成本估算外,在执行计划中还存在其他几个值得关注的关键属性: - **Starts**: 表示某个特定的操作被执行了多少次; - **E-Rows (Estimated Rows)**: 预估此步将会产生的数据行数目; - **%CPU**: 显示当前节点所占总预期CPU时间的比例。 理解并合理利用这些参数有助于识别潜在瓶颈所在位置以及可能存在的低效模式[^3]。 #### 4. 实际案例中的应用技巧 当面对具体的应用场景时,可以通过调整索引结构、重写复杂子查询为JOIN表达式等方式尝试降低整体开销。此外,定期更新表对象上的统计信息也是保持良好性能不可或缺的一环。 ```sql -- 更新表的统计信息 BEGIN DBMS_STATS.GATHER_TABLE_STATS( ownname => 'SCHEMA_NAME', tabname => 'TABLE_NAME' ); END; / ``` 通过以上方法能够有效提升SQL语句的表现力,并减少不必要的等待时间和资源浪费现象发生。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值