共计 1747 个字符，预计需要花费 5 分钟才能阅读完成。
本文摘要：
在某些非凡情景下，DBLE 无奈将关联查问语句正确下压到数据节点，进而导致执行异样。
本文详细分析了此种景象产生的起因，并提供了解决方案。
作者：林海
华夏银行数据库专家，专一于开源及国产分布式数据库技术，多年一线金融行业数据库开发与运维教训。目前次要负责分布式数据库的钻研、利用与推广工作。
本文起源：原创投稿
* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。
一、前言
采纳分布式数据库中间件模式时，咱们将业务表依照某种特定的算法和规定扩散到了多个业务子表当中。中间层对利用屏蔽后端拆分细节、解析客户端 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 问题大家能够踊跃反馈给社区解决，通过产品升级或者采取长期计划来防止问题产生。
