阿里禁止>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<House> 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 简单高效的低代码开发框架