主表1条记录关联子表a（3条）和子表b（5条）时，left join并列会导致3×5=15行笛卡尔积式膨胀，count/sum被重复计算；正确做法是先用子查询按main_id分别聚合子表，再left join回主表，或mysql 8.0.14+使用lateral避免交叉放大。
直接JOIN多个子表会导致行数爆炸
主表1条记录，子表A有3条，子表B有5条，LEFT JOIN两个子表后，结果会变成15行——不是3+5=8，而是3×5=15。数据库把A的每条记录和B的每条记录都配了一遍，这就是“笛卡尔积式放大”。你看到的COUNT、SUM值全被重复计算了。
常见错误写法：SELECT m.id, COUNT(a.id), COUNT(b.id) FROM main_table m LEFT JOIN detail_a a ON a.main_id = m.id LEFT JOIN detail_b b ON b.main_id = m.id GROUP BY m.id。这个查询看似合理，实际统计值会严重失真。
- 只要子表之间没有天然的一一对应关系（比如订单明细和物流单），就别让它们在同一个FROM里并列JOIN
-
GROUP BY不能解决这个问题，它只对已生成的15行做聚合，而不是还原逻辑上的“每个主表一行” - 即使加了
DISTINCT，对COUNT或SUM也无效，因为重复行里的值本身是真实的，只是不该被多次计入
用子查询分别聚合再关联
把每个子表先按main_id聚合成一行，再用LEFT JOIN连回主表。这样主表每行只对应子查询结果的一行，彻底避开交叉放大。
正确写法示例：SELECT m.id, a.cnt, b.total FROM main_table m LEFT JOIN (SELECT main_id, COUNT(*) AS cnt FROM detail_a GROUP BY main_id) a ON a.main_id = m.id LEFT JOIN (SELECT main_id, SUM(amount) AS total FROM detail_b GROUP BY main_id) b ON b.main_id = m.id
- 子查询必须带
GROUP BY，否则会返回多行导致主表被重复展开 - 子查询别名（如
a、b）要在ON条件里用，不能写成ON a.main_id = m.id这种语法错误 - 如果某个子表为空，对应字段会是
NULL，需要时可用COALESCE(a.cnt, 0)转为0
用LATERAL（MySQL 8.0.14+）替代嵌套子查询
当子表聚合逻辑复杂（比如要算中位数、去重计数、带窗口函数），子查询写在外面会难以维护。MySQL 8.0.14起支持LATERAL，允许子查询引用外层表字段，写法更紧凑。
等价写法：SELECT m.id, a.cnt, b.total FROM main_table m LEFT JOIN LATERAL (SELECT COUNT(*) AS cnt FROM detail_a WHERE main_id = m.id) a ON TRUE LEFT JOIN LATERAL (SELECT SUM(amount) AS total FROM detail_b WHERE main_id = m.id) b ON TRUE
-
LATERAL子查询里能直接用m.id，不用提前GROUP BY，逻辑更贴近业务意图 -
ON TRUE是必需的，因为LATERAL本身不提供连接条件，只是声明“这个子查询依赖m” - 低版本MySQL不支持
LATERAL，强行使用会报错ERROR 1064，务必确认版本
聚合字段类型不一致时要小心隐式转换
如果子查询返回的字段类型和主表字段不一致（比如子查询SUM()返回DECIMAL，主表字段是INT），某些MySQL配置下会触发截断或警告，影响统计精度。
- 显式转换更安全：
CAST(b.total AS DECIMAL(12,2)) - 聚合结果为空时返回
NULL，不是0；如果业务要求默认值，必须用COALESCE包裹 - 子表数据量极大时，子查询的
GROUP BY可能成为性能瓶颈，需确保main_id上有索引
真正难的不是写出语法正确的SQL，而是判断哪些聚合该提前做、哪些必须留到主查询里——这取决于字段间是否存在逻辑耦合。比如“子表A的最新创建时间”和“子表B的最早完成时间”不能简单拆成两个独立子查询，得看业务是否要求它们属于同一笔关联事件。
