所有带join的sql可否拆成若干sql执行

有若干个表在两个库上,且需要join这若干个表,这类join的sql理论上可否拆成若干个sql执行

我觉得还是得具体业务具体分析,left jon的可能分开可以,inner join的在一起应该查询的更快一点

1 个赞

理论上是可以

1 个赞

你的意思,A库上3个表,B库上2个表,这5个表inner join,想要先在A库inner join那三个,然后在B库inner join那三个?然后inner join这两个结果集?你在哪join这俩结果集呢?

1 个赞

有些场景,适当的冗余和打宽会更有效…

1 个赞

理论上可以把,看具体情况,太多表join还是得从表设计来思考吧

1 个赞

在业务系统join这两个结果

拆开肯定是可以的,但这需要应用对多个结果集进行关联处理,应该是需要应用做改造的吧。应用能答应干这事儿?

1 个赞

不同的库是值不同的集群,然后用应用服务器做计算操作来解决跨库问题?

1 个赞

我觉得能代码做的尽量代码做,毕竟服务器资源便宜

1 个赞

是的,我不懂的是join的sql是否可以拆成若干子sql分别在两个库执行,并在应用端做合并操作

逻辑捋顺了,都是可以拆分的

1 个赞

by chatgpt

理论上,可以将这些 join 操作拆分成多个 SQL 查询来执行。但是,在拆分过程中需要考虑以下几个因素:

  1. 数据一致性:拆分后的多个查询可能会导致数据不一致,需要确保数据的完整性和正确性。
  2. 性能:由于需要执行多个查询,可能会影响整体的性能表现。需要对查询进行优化,避免重复扫描数据等操作。
  3. 可维护性:拆分后的代码可能比较复杂,需要注释清晰、易读易理解,方便日后维护。
  4. 事务管理:如果需要在多个查询之间保持事务一致性,则需要在程序中进行显式的事务管理,以确保所有操作都成功或回滚。

总结来说,虽然可以将 join 操作拆分成多个 SQL 查询来执行,但需要综合考虑以上因素,并评估是否值得这种做法。

1 个赞

inner join的话肯定可以,但是应用层面处理效率能达到业务要求吗?

引入临时中间表,内存表或实体表,理论上都可以将所有类型的 join sql拆分。

但是实际操作时,为了保证数据准确性和资源使用的平衡性,可能需要做比较多的分析和验证工作,需要结合业务综合评估

1 个赞

我昨天问过类似的 join sql 拆分问题,我是来学习的

其实是不建议这么做的,要知道你在数据库做一些连接计算啥的还是会有一些优化的