一、前言
采用分布式数据库中间件模式时，我们将业务表按照某种特定的算法和规则分散到了多个业务子表当中。中间层对应用屏蔽后端拆分细节、解析客户端 SQL 请求并转发至后端数据库，整个过程由中间件进行 SQL 解析、重写、路由、执行、结果集归并。对于每一个执行过程，我们一般希望语句能完整地下压至多个后端数据库节点，以达到并行计算的目的。然而有些关联查询语句却可能无法达到我们的预期。它会把语句拆分执行，然后将结果集提升到 DBLE 层匹配计算。这就造成了 DBLE 的 CPU 升高、语句执行耗时严重的问题。极端情况下更可能会造成 DBLE 无法对外提供服务。什么样的语句会造成这种情况？我们下面逐一说明。
二、演示及优化
环境检查 DBLE 版本：2.19.11.1 MySQL 版本：5.7.28 涉及分片表：h_tempinvm、h_acsn 涉及全局表：brhm 分片拆分规则：stringhash 节点数量：4
下面将通过四个示例来展示造成 DBLE 压力升高的情况及优化方式。
2.1 分片规则不一致：
结论：关联查询表分片规则不同，关联语句无法正确下压。
分片表 h_acsn、h_tempinvm 关联查询语句如下：
分片规则如下：
通过配置可见拆分算法 function 是不同的。
执行计划如下：
执行计划可见，DBLE 对语句进行了拆分。分别在每个数据节点扫描两张表后，将各自结果集合并排序后，在 DBLE 层做 MERGE、JOIN 操作。
调整分片规则如下：
调整后执行计划如下：
语句已完全下压至后端数据节点，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 操作。临时解决是将全局表变更为分片表使用。
三、总结
示例 2.2 分片规则不一致、2.3 关联条件未使用分片键是在项目设计初期就可以避免的，我们在选择拆分算法时 function 配置需保证 patitionCount[ ]、patitionLength[ ] 两个数组及 hashSlice 二元组一致。
示例 2.4 全局表位置影响问题已经反馈社区，大家可静待版本修复。
示例 2.5 多张分片表与全局表关联查询问题已在 2.19.11.99 版本修复，如有需要大家可升级 DBLE 版本来解决。
通过以上示例执行情况可以看出，在使用 DBLE 时，关联查询应确保分片规则一致及使用分片键，DBLE 在进行 SQL 解析路由时是会判断分片规则的，分片规则一致的 SQL 会下发到后端每个分片执行，计算结果返回 DBLE 层做 MERGE 操作，相反会将 SQL 语句拆分下发，将后端分片数据所有数据提到 DBLE 层进行 MERGE、JOIN 计算操作。涉及到 DBLE 产品 BUG 问题大家可以积极反馈给社区解决，通过产品升级或者采取临时方案来避免问题发生。