本文摘要:
在某些特殊情形下,DBLE无法将关联查询语句正确下压到数据节点,进而导致执行异常。
本文详细分析了此种现象产生的原因,并提供了解决方案。
作者:林海
华夏银行数据库专家,专注于开源及国产分布式数据库技术,多年一线金融行业数据库开发与运维经验。目前主要负责分布式数据库的研究、应用与推广工作。
本文来源:原创投稿
*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。
一、前言
采用分布式数据库中间件模式时,我们将业务表按照某种特定的算法和规则分散到了多个业务子表当中。中间层对应用屏蔽后端拆分细节、解析客户端 SQL 请求并转发至后端数据库,整个过程由中间件进行 SQL 解析、重写、路由、执行、结果集归并。对于每一个执行过程,我们一般希望语句能完整地下压至多个后端数据库节点,以达到并行计算的目的。然而有些关联查询语句却可能无法达到我们的预期。它会把语句拆分执行,然后将结果集提升到 DBLE 层匹配计算。这就造成了 DBLE 的 CPU 升高、语句执行耗时严重的问题。极端情况下更可能会造成 DBLE 无法对外提供服务。什么样的语句会造成这种情况?我们下面逐一说明。
二、演示及优化
环境检查
DBLE 版本:2.19.11.1
MySQL 版本:5.7.28
涉及分片表:h_tempinvm、h_acsn
涉及全局表:brhm
分片拆分规则:stringhash
节点数量:4

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

被折叠的 条评论
为什么被折叠?



