![](https://img-blog.csdnimg.cn/20190927151117521.png?x-oss-process=image/resize,m_fixed,h_224,w_224)
sql优化
都是真实生产环境sql优化案例,每条案例都是经典的
dba任意
DBA
展开
-
sql优化,生产真实案例7
执行1500万次,执行计划如下,对TBLMITEMCCLASS2MITEM全表扫描,cost为181。造成多对多的关联,其实count的值并不对,原本应该count为0,缺少此条件导致count部位0。建议修改为如下,由于对于具体数值无要求,改为取rownum=1,再count,即可判断是否为0。而且根据package中的内容,这个sql也仅用于判断是否为0,不考虑具体数值。造成全表扫描的原因是把两列进行拼接,导致无法用上索引。并且根据业务反馈,原有sql其实还缺少关联条件。原创 2023-08-03 10:26:46 · 35 阅读 · 0 评论 -
sql优化,生产真实案例6
当前执行计划全表扫描,cost为9000多。仅用于判断是否大于0,对于具体数字无要求。执行计划的cost为5,检索索引。执行次数十几万,每次0.46秒。查看该package中的逻辑。原创 2023-08-03 09:59:00 · 41 阅读 · 0 评论 -
sql优化,生产真实案例5
修改参数类型后,执行速度依然没有改善,原因应该是该sql中is null or 这种语法太多,导致执行计划不正确,这种情况以前在其他程序里也出现过。而如果将package中sql查询的那段SQL代码复制出来,代入查询条件却不慢,仅仅是执行存储过程慢,收集sql查询到的表的统计信息也没有作用。对于PLSQL中的执行计划,分析时需要通过10046这种跟踪才能准确找的出来,后续遇到此类问题时可以作为参考。查看文本文件内容,其中下图中的执行计划显示fetch了200多万行。生产库查询存储过程执行慢。原创 2023-08-03 09:14:17 · 36 阅读 · 0 评论 -
sql优化,生产真实案例4
高频执行sql 6wgswwwgrm66a 索引优化1、单表查询,查看执行计划,索引 WTDOCUMENT$COMPOSITE5 返回2523行记录,而最终只返回2行记录,索引选择性不好2、查看where条件相关列的数据分布,重建索引。原创 2023-08-03 08:57:07 · 54 阅读 · 0 评论 -
sql优化,生产真实案例3
优化表MP_CHAT_READED_COUNT的索引,建立(chatid,fromuserid)列的组合索引。对比libary cache中该sql对应的child cursor的平均执行时间和逻辑读。对比该sql截止目前的所有child_cursor的平均执行时间。2、查看执行效率最差的子cursor的child_number。待优化SQL_ID : 7frm2t109ra7a。3、查看该child_number的绑定变量值。5、查看效率最差的子cursor的执行计划。原创 2023-08-02 14:37:07 · 35 阅读 · 0 评论 -
sql优化,生产真实案例2
物化视图统计信息陈旧导致job 执行时间过长原创 2023-08-02 14:26:04 · 40 阅读 · 0 评论 -
sql优化,生产真实案例1
3、获取sql_text,手动执行,收集执行计划,发现执行时间和逻辑读主要消耗在对 BARCODE 列的索引扫描 PK_TBLWHOUTSTORAGE_DETAIL,扫描方式为 INDEX SKIP SCAN。查看top sql,sql_id: 51gg2h8q0t65r 执行次数和消耗cpu较多,优化索引解决。6、重新执行sql,发现执行时间降为 0.01s,逻辑读降为34 ,优化完成。2小时内执行12368次,平均执行1.2s,平均逻辑读 67087。2、查看sql执行计划。原创 2023-08-02 11:57:30 · 49 阅读 · 0 评论