有若干个表在两个库上，且需要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 个赞
理论上，可以将这些 join 操作拆分成多个 SQL 查询来执行。但是，在拆分过程中需要考虑以下几个因素：
- 数据一致性：拆分后的多个查询可能会导致数据不一致，需要确保数据的完整性和正确性。
- 性能：由于需要执行多个查询，可能会影响整体的性能表现。需要对查询进行优化，避免重复扫描数据等操作。
- 可维护性：拆分后的代码可能比较复杂，需要注释清晰、易读易理解，方便日后维护。
- 事务管理：如果需要在多个查询之间保持事务一致性，则需要在程序中进行显式的事务管理，以确保所有操作都成功或回滚。
总结来说，虽然可以将 join 操作拆分成多个 SQL 查询来执行，但需要综合考虑以上因素，并评估是否值得这种做法。
1 个赞
inner join的话肯定可以，但是应用层面处理效率能达到业务要求吗？
引入临时中间表，内存表或实体表，理论上都可以将所有类型的 join sql拆分。
但是实际操作时，为了保证数据准确性和资源使用的平衡性，可能需要做比较多的分析和验证工作，需要结合业务综合评估
1 个赞
我昨天问过类似的 join sql 拆分问题，我是来学习的
其实是不建议这么做的，要知道你在数据库做一些连接计算啥的还是会有一些优化的