关于Mysql一对多leftjoin时SUM数据翻倍的问题

在最近的任务中，需要编写报表合计，但是Mysql表中有张表是1对多的情况

但过去的业绩报表中未出现此问题，我意识到可能是当时我查询的量表不同，在查询门店时只查询了主表未连接子表，而查询专柜时虽然主表与子表连接，但SUM数据查询的是子表数据而非主表数据，所以未出现SUM翻倍的情况。

这次出现这种情况是因为，需要SUM实际金额与销售金额，而数据库中的子表测试数据并不完整，有很多为空的字段与主表字段对接不上，只能硬查主表数据才导致了SUM问题翻倍的发生。自我推测，在正式环境的数据库中应该不会出现子表主表数据不一致的情况。

但是问题还是要解决的，所以我查询了一下网上的资料，解决方案如下：

1.避免直接lefj join 查询，先查询子表，再将子表查询结果与主表结果关联

2.先不进行SUM而是将leftjoin后的数据进行SUM

这样得出来的结果便是正确的，这个是自己想的，但说实话这种方式真的巨差无比，我想我写完没过几天就会看不懂自己写的代码，代码难看，而且耦合性高，所以强烈不建议这种。

3.查询后的结果在JAVA后台计算相加，这个方法较为复杂，而且程序计算量高，暂且不论

所以以目前查询到的资料与思考综合起来而言，leftjoin子表查询结果才是最优解

但是我一直有个疑问就是加入子查询不会拖慢查询速度吗，然后在咨询下的评论区有个老哥解答了我的疑惑：

有这么一个说法：当你的子查询在from后面并且是不相关子查询的时候（就是你的子查询和外表没有联系的时候）sql
语句执行是先把子查询查询出来当做一个表然后进行表连接，表连接的性能损耗很小。当你的子查询在select里面的时候每次需要先将主查询查询出一条符合的数据然后再查询一遍子查询。那么假如主查询有上w条数据 from只要走一遍子查询而select里面的却要走上w次。效率差距不是显而易见吗

参考链接：https://blog.csdn.net/m0_47005349/article/details/117257409

　　　　　https://blog.csdn.net/QQ826688096/article/details/89351317