sql优化——一百万条数据查询插入慢

举报
田逸嘉 发表于 2023/10/11 15:57:28 2023/10/11
【摘要】 【问题根因】 计算倾斜影响效率:在查询执行的过程中,join key、group by key等往往不是表的分布列,因此需要按照join key、group by key上数据的hash值,让数据在各个DN之间进行重新分布,这个过程对应于计划中的Redistribute算子。当重分布列上的数据存在倾斜时,就会导致运行时的数据倾斜,即重分布后部分节点的数据远远大于其他。倾斜节点需要处理更多的数...

【问题根因】 计算倾斜影响效率:在查询执行的过程中,join key、group by key等往往不是表的分布列,因此需要按照join key、group by key上数据的hash值,让数据在各个DN之间进行重新分布,这个过程对应于计划中的Redistribute算子。当重分布列上的数据存在倾斜时,就会导致运行时的数据倾斜,即重分布后部分节点的数据远远大于其他。倾斜节点需要处理更多的数据,导致倾斜节点的计算性能远远低于其他节点。

【定位过程】 问题的每个排查方向的排查结果

1、客户语句为5表关联单层查询后,直接插入目标表;

2、performance显示select各个步骤都存在计算倾斜的问题;

3、原复制表Streaming type为  PART REDISTRIBUTE PART ROUNDROBIN),把复制表改成普通表之后,计划走了broadcast,执行效率达到客户预期;

解决方案:

1、表的分布方式改为哈希分布;

2、 /*+ leading((((s1 war)pro)acc)sta) */ ,或

/*+ leading((((s1 pro)sta)war)acc) */

hint固定join顺序

3、hint/方式指定小表做 /*+ broadcast(STA)/避免计算倾斜;

4、先创建一个session级的临时表,避免对业务表直接插入数据。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。