对于分布式数据库在多表关联、聚合查询性能偏弱的问题，有什么思路吗？

我们在实践中，也遇到过类似的问题，比如分布式数据库对于存储过程不支持。由于原来使用了db2，把一部分应用逻辑放在了数据库的存储过程里。我们的做法是，把逻辑交回给应用，应用做代码改造。题主这一具体问题，我们还没有遇到，所以无法给出实践参考。
不过，从我们的实践角度出发，引入分布式数据库后，代码改造是不可避免的，目前不可能平滑100%兼容，所以原来对于db2等传统数据库的习惯，势必要改的。所以，在引入分布式数据库之前，建议充分评估兼容性，和代码改造量，评估是否可接受。否则，一旦引入后再去推动代码改造，又是一番问题。

最后一个问题，我们从运维的角度出发，给dba提供了一些转型建议：
1 、制定规范和标准，降低运维风险
例如把升级、上线、备份、迁数等工作整理成标准模板文档，形成运维资产随时调用；或更进一步地，把数据建模和数据库设计、容量规划、 SQL 开发、高可用架构设计等工作整理成规范文档，面向所有数据库开发人员提供咨询指导。
2 、借助运维工具，发展自动化、平台化运维
常规序列化操作如安装、巡检、升级、备份等，借助自动化运维平台；以往通过手工更新的数据库配置信息表交给配置管理系统来管理；数据库的监控告警可以利用近几年大热的 Prometheus+grafana 技术进行配置，或者引入商用产品建设数据库监控平台或数据库性能分析系统；等等
3、主动拥抱新技术
自主搭建一套测试环境进行学习实践是转型的开端。
4、 懂技术，也要懂业务和管理
数据库运维人员一定要从项目前期调研就开始参与，因为项目前期所进行的调研、需求、 poc 测试是了解新技术的第一步，可以最快速地了解市场主流技术和应用现状。到了项目建设期，就更需要技术和管理的复合型人才了，数据库运维人员自身已经有了技术实力，更能方便地把业务需求与实践相结合，利于项目成功落地。项目建成后进行新技术推广时，技术人员的优势又能进一步凸显，因为无论是何种新技术的推广实施，一定要先制定完善的技术升级规范，提前做好测试。