多对多JOIN后SUM/COUNT错误是因隐式行膨胀，须将聚合上提至JOIN前；正确解法是用子查询预聚合（如LEFT JOIN (SELECT user_id,COUNT(*) FROM t GROUP BY user_id)），并确保过滤条件在子查询内、字段类型一致。
多对多关系表 JOIN 后用 SUM 或 COUNT 得到错误结果，不是 SQL 有 bug，而是 JOIN 生成了隐式重复行——必须把聚合“上提”到 JOIN 前，否则所有后续计算都基于膨胀后的物理行，结果必然失真。
为什么多对多 JOIN 后 SUM 会翻倍？
根本原因是中间关联表（如 user_role）让主表一行被复制多次。比如一个用户关联 3 个角色、2 个标签，JOIN 后就产生 3 × 2 = 6 行，SUM(role_salary) 就被加了 6 遍，而不是按用户逻辑加 1 次。
- 用
SELECT COUNT(*) FROM user u JOIN user_role ur ON u.id = ur.user_id GROUP BY u.id查每用户对应多少行，就能确认是否已膨胀 -
DISTINCT在SUM里加不解决问题：SUM(DISTINCT price)是去数值重复，不是去行重复，业务语义全错 - 执行计划里如果
rows列远大于主表行数，基本可断定是 JOIN 膨胀导致
用子查询预聚合：最通用且可靠的解法
核心思路是：先在中间表或从表里按业务主键（如 user_id）算好汇总值，再和主表 LEFT JOIN。这样每条主表记录只参与一次计算。
- 子查询必须带别名，例如
(SELECT user_id, COUNT(*) AS role_count FROM user_role GROUP BY user_id) AS r，否则 MySQL 报Error Code: 1248 - 过滤条件（如
status = 'active'）必须写在子查询内部，不能挪到外层WHERE，否则LEFT JOIN退化为INNER JOIN - 主表字段类型必须和子查询中关联字段一致，比如
users.id是BIGINT，user_role.user_id也得是BIGINT，别用CAST强转，否则索引失效 - 示例（统计每个用户的角色数和标签数）：
SELECT u.id, u.name,<br> COALESCE(r.role_count, 0) AS role_count,<br> COALESCE(t.tag_count, 0) AS tag_count<br>FROM users u<br>LEFT JOIN (SELECT user_id, COUNT(*) AS role_count FROM user_role GROUP BY user_id) AS r ON u.id = r.user_id<br>LEFT JOIN (SELECT user_id, COUNT(*) AS tag_count FROM user_tag GROUP BY user_id) AS t ON u.id = t.user_id;
需要同时返回明细和汇总时，用窗口函数更干净
当你要查“每个订单的所有明细行，并附带该订单总金额”，就不能用传统 JOIN+GROUP BY（它会压缩行数），而要用 SUM() OVER——它不改变行数，只在每行上附加计算结果。
-
SUM(price) OVER (PARTITION BY order_id)是按订单分组求和，不会引入重复行 - 若还需关联主表字段（如订单创建时间），应先用窗口函数处理明细表，再
LEFT JOIN orders，而不是反过来 - 注意兼容性：MySQL 8.0+、PostgreSQL、SQL Server 2017+ 支持；老版本 MySQL 只能靠子查询或应用层拼接
- 错误写法：
SELECT *, SUM(price) FROM order_items JOIN orders ... GROUP BY order_id—— 这里GROUP BY已经丢掉了明细维度
视图封装逻辑：适合高频复用但不解决性能问题
把预聚合逻辑固化进视图，能提升可读性和复用性，但它只是语法层封装，不改变执行计划。基础逻辑写错，视图照样错。
- 视图定义中必须用
LEFT JOIN+GROUP BY+ 所有非聚合字段，例如：CREATE VIEW user_with_stats AS SELECT u.id, u.name, COALESCE(r.cnt, 0) FROM users u LEFT JOIN (SELECT user_id, COUNT(*) AS cnt FROM user_role GROUP BY user_id) r ON u.id = r.user_id GROUP BY u.id, u.name - 别在视图里加
WHERE或ORDER BY，会锁死使用场景；过滤和排序留给调用方 - CTE 写在视图里没实际收益，会被内联展开，不物化也不缓存，纯属多写几行
- 真正容易被忽略的是：视图无法规避 JOIN 膨胀本身，它只是把“正确写法”藏起来了——如果底层子查询漏了
GROUP BY或类型不一致，问题照旧
