关于java:阿里禁止3张表的JOIN为什么咋解决

1. 阿里为何禁止大于三张表的JOIN？

此标准是针对MySQL系数据库的，模仿一些场景多造些数据去查问比照不难发现：每减少1张表的JOIN，查问性能就会显著降落。

比方上面这个场景（3张表各100W数据，集体PC测试）：

3张表的JOIN连贯查问耗时3s多，如果再去JOIN一个字典表，耗时将在5s多。
多JOIN一张表对性能的影响是比拟大的。

2. 应该怎么解决能力尽量避免多表JOIN呢？

diboot框架很好的解决了这个问题，diboot内核除了简化关联场景的SQL外，还通过拆解JOIN为单表查问实现了 高性能。让大家在写的更少的同时，也使零碎性能达到更优。

上面咱们以上述场景的测试数据比照，来看看diboot关联绑定带来的性能晋升有多大吧。
场景：“居民” 与 “房产”的N-N关联场景，3张表各100W数据，两头表关联字段均有索引，集体PC测试。
需要：查问返回一页“居民”主表数据，并关联其“房产”数据，VO示意如下:

public class CitizenVO  {
    // 关联对象汇合
    private List houseList;
    //性别字典：GENDER
    private String genderLabel;
}

习惯Mybatis写SQL的同学，可能在想这段SQL该怎么写了，而应用diboot只须要增加两行注解，通知diboot他们之间的关联关系即可。

性能比照测试后果能够看到，绝对于手写SQL的4s+耗时，diboot仅需0.4s左右即可实现查问绑定，性能晋升近10倍。当数据量再大的时候，手写SQL会越来越慢，而diboot仍然能够稳固在<1s，性能晋升将轻松超过10倍。

这个比照测试也验证了diboot关联绑定的理论依据：《高性能MySQL》一书中“重构查问形式”的优化倡议的正确性，而且数据量越大，关联场景越简单，应用diboot关联绑定的性能劣势越显著。

所以：别再手写关联SQL了，diboot用起来，写的更少，性能更好！

参考资料：
看文章理解 diboot 如何做到高性能的？

看视频理解 diboot 如何做到进步查问性能的

diboot 简略高效的低代码开发框架