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 简略高效的低代码开发框架