资讯专栏INFORMATION COLUMN

案例分享:Gbase慢sql优化案例

IT那活儿 / 3347人阅读
案例分享:Gbase慢sql优化案例

点击上方“IT那活儿”公众号,关注后了解更多内容,不管IT什么活儿,干就完了!!!


慢SQL

此处的sql是相同类型的测试sql,方便大家阅读。首先把sql拿到生产测试发现确认要很长时间,跑了几分钟根本跑不出来。

Sql: select
a.u_id,
b.b_id,
c.c_id,
from a.a a
left join b.b b on a.u id=b.u_id
left join c.c c on b.c_id=c.c_id
limit 100000;


慢SQL优化

1. 尝试去除一个left join条件
等了一会跑出来了。
耗时1分50秒。
2. 再看表数据量
  • a表 四万条记录
  • b表将近八千万条记录
查询方式也符合查询逻辑,大小表关联查询一般用小表驱动大表。
3. 尝试用in 
 有一定的提升,但是根据业务逻辑需要用到b表中很多的字段,而in后面的字段,只能有一个 。

4. 改变思路看表的分布方式

  • 复制表:isReplicate=YEShash
  • 分布表:hash_column= col_name,分布键是col_name
  • 随机分布表:isReplicate=NO,hash_column=null
可以看到小表a是随机分布表。大表b是哈希分布表。
再看执行计划:

显示界面主要组成部分:

  • ID:SQL执行步骤,顺序从下向上;
  • MOTION:某个步骤的结果处理方式;
  • OPERATION:某个步骤内的具体执行操作;
  • TABLE:某个operation涉及的表;
  • CONDITION:某个operation操作涉及的条件。
可以看到Motion列有个BROADCAST步骤。
因为小表是随机分布,即使大表是哈希分布也无法走分布键,所以小表拉了复制表。这个笔者理解应该是类似重广播,就是每一个节点都会有一份复制表。
5. 测试如果小表加上分布键会不会提升查询速度
因为Gbase无法在表建成后加分布键 所以新建一张测试表。
需要注意括号内的字段加单引号再将数据导入。
测试:
结果是毫秒级,如果不加分布键则需要1分50秒。
再看执行计划:
没有了BROADCAST这个步骤。于是将结果与建议反馈业务侧。


本文作者:徐 瑞(上海新炬王翦团队)

本文来源:“IT那活儿”公众号

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/129168.html

相关文章

  • 2021年9月国产数据库大事记

    .markdown-body{word-break:break-word;line-height:1.75;font-weight:400;font-size:15px;overflow-x:hidden;color:#333}.markdown-body h1,.markdown-body h2,.markdown-body h3,.markdown-body h4,.markdown-body...

    suemi 评论0 收藏0
  • 数据库收集 - 收藏集 - 掘金

    摘要:前言在使用加载数据数据库常见的优化操作后端掘金一索引将放第一位,不用说,这种优化方式我们一直都在悄悄使用,那便是主键索引。 Redis 内存压缩实战 - 后端 - 掘金在讨论Redis内存压缩的时候,我们需要了解一下几个Redis的相关知识。 压缩列表 ziplist Redis的ziplist是用一段连续的内存来存储列表数据的一个数据结构,它的结构示例如下图 zlbytes: 记录整...

    Little_XM 评论0 收藏0

发表评论

0条评论

IT那活儿

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<