业务架构引入dble后，应用端SQL需要遵循哪些原则进行改造？

[Dinosauria]

随着数据量的增大，应用架构引入dble后，性能提升不明显，此时需要如何处理？

[Dinosauria]

方向

此时可以从两个方向入手：

1. 那就是引入中间件后，并不是引入之后就没事了，此时也引入了复杂性，应用端需要进行适当的调整，具体可参考下面的改造指南
2. 如果应用端改造完成之后，性能提升还是不明显，需要调整dble参数提高性能。可以参考此文章：dble性能测试的数据如何判断合理性？ #2851

基于分布式中间件的SQL改造指南

原始pdf详见 github地址：https://github.com/actiontech/slides/blob/master/201904-基于分布式中间件的SQL改造指南-孙正方-GOPS全球运维大会.pdf

SQL改造原则 - 总结

1. 简单查询以及ER查询：
   • 分片条件
   • 使用ER关系
2. 跨库JOIN：
   • 表格给分片条件，限定条件
   • 注意亲和性，优化关联顺序
   • 降低JOIN列的重复率

1 简单SQL处理

注意事项

• 内存：流式返回，无影响
• 延迟：等待最后一个节点
  添加分片条件，否则影响延迟

小结

• 中间件中表单查询属于简单SQL
• 广播SQL高并发对延迟有影响
• 使用分片条件查询能降低影响

2 普通分片表关联

注意事项

• 确保表格之间存在ER关系
• 下发到MySQL节点执行，广播类型注意延迟

小结

• 有从属关系使用ER关系
• ER关系表关联整体下发SQL
• 同样需要注意分片条件问题

3 跨库表关联

小结

1. 按照SQL本来的逻辑结构分别取数据执行
2. 按照JOIN列组织数据进行JOIN
3. SQL编写需要使得中间结果尽量少
   • 表限定条件
   • 调整亲和性
   • JOIN列重复低