摘要：
在某些特殊情况下，DBLE无法正确地将关联查询语句按到数据节点，从而导致执行异常。
本文详细分析了产生这一现象的原因，并提出了解决办法。
作者：林海
华夏银行数据库专家，专注于开源和国产分布式数据库技术，在一线金融行业拥有多年的数据库开发和运维经验。目前主要负责分布式数据库的研究、应用和推广。
来源：原创稿件
*爱克生开源社区制作的原创内容未经授权不得使用。转载请联系边肖并注明出处。
00-1010，在采用分布式数据库中间件模型时，我们按照一定的具体算法和规则，将业务表分散到几个业务子表中。中间层屏蔽应用程序的后端拆分细节，解析客户端的SQL请求并将其转发到后端数据库。整个过程是由中间件进行SQL解析、重写、路由、执行和结果集合并。对于每个执行过程，我们一般都希望语句能够完全压到多个后端数据库节点，达到并行计算的目的。但是，一些相关的查询语句可能不符合我们的预期。它将拆分并执行语句，然后将结果集提升到DBLE图层匹配计算。这导致DBLE的中央处理器增加，语句执行需要大量时间。在极端情况下，DBLE更有可能无法提供外部服务。什么样的说法会造成这种情况？让我们一个一个解释。
00-1010环境检查
DBLE版：2.19.11.1
MySQL版本：5.7.28
参与分片表：h _ tempenvm，h_acsn
涉及的全局表：brhm
拆分规则：stringhash
节点数：4
下面，将使用四个例子来说明DBLE压力增加的情况和优化方法。
00-1010结论：关联查询表有不同的分片规则，关联语句不能正确按下。
片段表h_acsn和H _ Tempinanvm的相关查询语句如下：
碎片规则如下：
通过配置可见的拆分算法功能是不同的。
实施计划如下：
执行计划显示，DBLE分裂了声明。在分别扫描每个数据节点中的两个表之后，收集并排序各自的结果，然后在DBLE层执行MERGE和JOIN操作。
按如下方式调整碎片规则：
调整后的实施方案如下：
d26ba535192278d0fc8?from=pc">语句已完全下压至后端数据节点，DBLE 层 MERGE 操作。
2.2 关联条件未使用分片键：
结论：关联查询条件未使用分片键，关联语句无法正确下压。
分片表 h_acsn、h_tempinvm 关联查询语句如下：
分片规则如下：
执行计划如下：
该执行计划与示例 1 无法下压情况相同，都是将语句做了拆分，在 DBLE 层 JOIN 操作。
2.3 全局表位置影响：
结论：当全局表作为驱动表时，语句无法正确下压。 全局表 brhm（驱动表）与分片表 h_acsn（被驱动表）关联查询语句如下：
分片规则如下：
执行计划如下：
执行计划可见语句并没有正确下压。
我们来调整一下，全局表 brhm（被驱动表）与分片表 h_acsn（驱动表）关联查询语句如下：
执行计划如下：
语句已完全下压至后端数据节点，DBLE 层 MERGE 操作。在程序逻辑不可更改情况下，临时解决是将全局表变更为分片表使用。
2.4 多张分片表与全局表关联查询：
结论：此问题为全局表处理逻辑 BUG。
分片表 h_acsn、h_tempinvm，全局表 brhm 关联查询语句如下：
分片规则如下：
执行计划如下：
执行计划可见，DBLE 对语句进行了拆分。两张分片表正常下压，全局表单独下压，结果集在 DBLE 层进行 JOIN 操作。临时解决是将全局表变更为分片表使用。