count(*)在left join后返回1而非0，是因为它统计结果集的物理行数，左表每行必生成一行（右表字段为null）；应改用count(orders.id)统计非null值才得0。
LEFT JOIN 后 COUNT(*) 返回 1 而不是 0，是因为它在数“组合行”
很多人以为 COUNT(*) 在 LEFT JOIN 后能反映“左表某行是否有关联数据”，结果发现没订单的用户也返回了 1。这不是 bug，是语义误解：COUNT(*) 统计的是结果集中的物理行数，而 LEFT JOIN 即使右表无匹配，也会为左表每一行生成一行（右表字段全为 NULL）。所以哪怕 orders.id 是 NULL，这行依然存在，COUNT(*) 就算 1。
真正该用的是 COUNT(orders.id) —— 它只统计非 NULL 值，右表无匹配时自然得 0。
-
COUNT(*)→ 算“有多少行”，左表每行必出 1 行，结果永远 ≥ 左表行数 -
COUNT(orders.id)→ 算“有多少个有效订单 ID”，NULL被跳过，无匹配即为 0 - 若误用
COUNT(*)再套COALESCE(..., 0)，毫无意义：它本来就不会是NULL
AVG/SUM 返回 NULL 不是错误，但应用层常把它当 0 用
AVG(orders.amount) 或 SUM(orders.amount) 在右表全无匹配时返回 NULL，这是标准行为（聚合函数自动忽略 NULL，空集合结果就是 NULL）。问题出在 Java、Python 或前端直接把 NULL 当成缺失值处理，或映射到非空字段时报错。
需要兜底时，必须在聚合函数**内部**处理，而不是对结果再 COALESCE：
- ✅
COALESCE(AVG(orders.amount), 0)—— 正确：先算 AVG，再转 0 - ✅
AVG(COALESCE(orders.amount, 0))—— 语义不同：把每笔 NULL 订单金额当成 0 参与平均（可能拉低均值） - ❌
AVG(orders.amount)直接丢给 Java 的double字段 —— JDBC 无法把 SQLNULL转基本类型，抛Cannot set property
WHERE 条件放错位置，让本该是 0 的变成 NULL 或干脆消失
写 LEFT JOIN ... WHERE orders.status = 'paid' 看似合理，实则把 LEFT JOIN 变成了事实上的 INNER JOIN：所有 orders.status 为 NULL（即无订单）的行，被 WHERE 过滤掉了。结果里根本看不到“0 订单”的用户，更别说返回 0 了。
要保留左表全部，并只统计“已支付”订单，条件必须进 ON：
- ❌
LEFT JOIN orders ON u.id = o.user_id WHERE o.status = 'paid'→ 过滤掉 NULL 行 - ✅
LEFT JOIN orders ON u.id = o.user_id AND o.status = 'paid'→ 无匹配时o.*全NULL，COUNT(o.id)得 0 - 如果还用
SUM(o.amount)，记得搭配COALESCE(SUM(o.amount), 0)，否则空组返回NULL
子查询预聚合才能真正避免“0 变成 NULL”或“0 被吞掉”
当右表一对多（比如一个用户有 5 条订单记录），直接 LEFT JOIN + GROUP BY 容易因行膨胀导致聚合失真：你本想统计“每个用户的订单数”，结果 COUNT(*) 返回 5，而 COUNT(orders.id) 才是 5 —— 但如果后续还要加其他表（如商品分类），重复行会进一步污染 SUM 和 AVG。
唯一稳住逻辑的方式，是在 JOIN 前把右表压成一行/键：
- 子查询必须
GROUP BY关联字段（如user_id），且过滤条件（status,deleted）全在里面 - 外层
ON必须严格匹配子查询的分组键，不能漏字段 - 示例中
COALESCE(o.order_cnt, 0)的0才真正代表“该用户无符合条件订单”，不是靠运气或类型转换硬凑出来的
跨多层维度（比如分类→品牌→商品→订单）时，这个模式不是可选项，是必选项；否则所谓“0 值”只是表象，背后可能是重复计算掩盖的真实偏差。
