分布式 | DBLE 关联查询下压优化

本文分析了DBLE在处理关联查询时可能出现的问题及其原因,并提供了几种优化策略。重点讨论了分片规则一致性、关联条件使用分片键的重要性,以及全局表在查询中的位置对性能的影响。

本文摘要:

在某些特殊情形下,DBLE无法将关联查询语句正确下压到数据节点,进而导致执行异常。

本文详细分析了此种现象产生的原因,并提供了解决方案。

作者:林海

华夏银行数据库专家,专注于开源及国产分布式数据库技术,多年一线金融行业数据库开发与运维经验。目前主要负责分布式数据库的研究、应用与推广工作。

本文来源:原创投稿

*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。

一、前言

采用分布式数据库中间件模式时,我们将业务表按照某种特定的算法和规则分散到了多个业务子表当中。中间层对应用屏蔽后端拆分细节、解析客户端 SQL 请求并转发至后端数据库,整个过程由中间件进行 SQL 解析、重写、路由、执行、结果集归并。对于每一个执行过程,我们一般希望语句能完整地下压至多个后端数据库节点,以达到并行计算的目的。然而有些关联查询语句却可能无法达到我们的预期。它会把语句拆分执行,然后将结果集提升到 DBLE 层匹配计算。这就造成了 DBLE 的 CPU 升高、语句执行耗时严重的问题。极端情况下更可能会造成 DBLE 无法对外提供服务。什么样的语句会造成这种情况?我们下面逐一说明。

二、演示及优化

环境检查

DBLE 版本:2.19.11.1

MySQL 版本:5.7.28

涉及分片表:h_tempinvm、h_acsn

涉及全局表:brhm

分片拆分规则:stringhash

节点数量:4

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值