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

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

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

对于分布式数据库在多表关联、聚合查询性能偏弱的问题，可以考虑以下思路：

1. 优化SQL语句：对于复杂查询、多表关联、聚合查询等这类较为复杂，涉及表较多的SQL,可以尝试优化SQL语句，减少不必要的连接和子查询等操作。
2. 使用索引：对于经常用于查询条件的字段，可以建立索引来提高查询效率。
3. 分库分表：将数据按照一定的规则分散到多个数据库或表中，可以减轻单个数据库或表的压力，提高查询效率。
4. 使用缓存：对于一些不经常变化的数据，可以使用缓存来提高查询效率。

5. 使用分布式计算框架：对于一些需要进行大规模计算的操作，可以使用分布式计算框架来提高计算效率。

   关于将这类处理交由程序去解决，数据库仅作简单的SQL处理这种用法是否合理，这取决于具体的业务场景和需求。如果业务场景比较简单，只需要进行简单的数据查询和统计分析，那么这种做法是可行的。但如果业务场景比较复杂，需要进行复杂的数据分析和挖掘，那么就需要考虑使用分布式计算框架等技术来提高计算效率。

   目前市面上有一些产品可以实现分布式数据库HTAP,例如华为的OceanBase、阿里云的MaxCompute、腾讯云的TDSQL等。这些产品都具有较强的分布式计算能力和高可用性，可以满足大部分企业的需求。

   如果分布式数据库HTAP技术能在三年之后趋于成熟，那么对我们现在分布式数据库的使用习惯和程序开发思维，可能会有以下启发：

6. 需要更加注重SQL语句的优化和索引的使用。
7. 需要更加注重数据的分库分表和缓存的使用。
8. 需要更加注重分布式计算框架的使用和技术的学习。

建设多表关联的场景、做一些大宽表，减少

个人观点：
1.尽量简化数据库的使用，特别是在分布式架构下，一方面可以减少复杂度，一方面减少可能的抖动。
2.纯原生分布式架构（如OB、TiDB）处理复杂查询，较分库分表的还是有优势的，可以在一定程度上解决部分复杂分析问题。
3.Oracle的优化器及软硬一体能力，表现比国产库好很多，这是短期内无法改观的。
4.更为复杂的查询需求，可考虑仍然使用ETL+MPP或流式查询来解决。
5.HTAP的实现能力，各产品有差异；对于开发上要有针对性的设计。