【案例】单SQL优化案例
【摘要】 打执行计划，发现存在倾斜，并且存在对大表做broadcast情况观察SQL，发现对该表做关联的条件并非该表的分布列。查询该表分别关于BALANCE_NO 以及 app_id(分布列)的倾斜情况修改分布列为’BALANCE_NO‘，该SQL的执行时间由62s优化到25s。重新打执行计划，观察到瓶颈点主要在nestloop算子。设置hint参数 enable_index_nestloop = o...
- 打执行计划，发现存在倾斜，并且存在对大表做broadcast情况
- 观察SQL，发现对该表做关联的条件并非该表的分布列。
- 查询该表分别关于BALANCE_NO 以及 app_id(分布列)的倾斜情况
- 修改分布列为’BALANCE_NO‘，该SQL的执行时间由62s优化到25s。
- 重新打执行计划，观察到瓶颈点主要在nestloop算子。设置hint参数 enable_index_nestloop = off; 后。SQL的执行时间优化到11s。
- 再观察执行计划，发现瓶颈主要在扫描表上面。于是在向客户确认过插入模型后，将行存表改为列存表。
- 并且观察到执行计划中存在统计信息不准的问题，关闭enable_extrapolation_stats参数。此时该SQL优化到6.7s。
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）