一条全表扫描sql语句的分析 (r4笔记第32天)
发布日期:2021-06-30 13:30:10 浏览次数:2 分类:技术文章

本文共 1058 字,大约阅读时间需要 3 分钟。

今天在对生产系统做监控的时候,发现一个process的cpu消耗很高,抓取了对应的session和执行的sql语句。发现是一个简单的update语句,这样一条如果CPU消耗较大,很可能是由于全表扫描的。UPDATECOMM_ACTIVITY SET COMM_ACTIVITY.EXTRACT_STATUS = NVL(:1 ,EXTRACT_STATUS), COMM_ACTIVITY.SOURCE_TYPE = NVL(:2 , SOURCE_TYPE),OPERATOR_ID = :3 , APPLICATION_ID = :4 , DL_SERVICE_CODE = :5 ,DL_UPDATE_STAMP = :6 , SYS_UPDATE_DATE = SYSDATE whereCOMM_ACTIVITY.ACTIVITY_CODE=:7 ANDCOMM_ACTIVITY.EXTRACT_STATUS=:8查看了对应的sql执行计划,发现和预期是一致的。Plan hash value: 557276772----------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |----------------------------------------------------------------------------------------| 0 | UPDATE STATEMENT | | | | 11187 (100)| || 1 | UPDATE | COMM_ACTIVITY | | | | ||* 2 | TABLE ACCESS FULL| COMM_ACTIVITY | 370K| 13M| 11187 (1)| 00:02:15 |----------------------------------------------------------------------------------------

对这样的一条语句,该怎么判定呢?INDEX_NAME TABLESPACE INDEX_TYPE UNIQUENES PAR COLUMN_LIST TABLE_TYPE STATUS NUM_ROWS LAST_ANAL G

转载地址:https://jeanron100.blog.csdn.net/article/details/102506988 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!

上一篇:MySQL和Oracle对比学习之数据字典元数据(r4笔记第33天)
下一篇:由hugepage设置导致的数据库事故(r4笔记第28天)

发表评论

最新留言

能坚持,总会有不一样的收获!
[***.219.124.196]2024年04月22日 15时52分33秒