LEFT JOIN后右表字段为NULL不会导致聚合函数报错，因SUM、AVG等会自动跳过NULL；报“无法设置属性”是Java基本类型映射NULL失败所致，需改用包装类或IFNULL/COALESCE在聚合前处理。
LEFT JOIN 后右表字段为 NULL 本身不会直接导致聚合函数报错，真正出问题的是：NULL 参与了某些不允许 NULL 的上下文（比如 Java 实体类的非空字段赋值、MySQL 的 strict mode 下插入、或聚合前未处理就参与了类型敏感运算），而聚合函数如 SUM、AVG、COUNT 本身对 NULL 是有明确定义行为的——它们不报错，只是跳过。
为什么聚合后查出来是 NULL，但程序却报“无法设置属性”？
这是典型的应用层映射失败，不是 SQL 层报错。比如 MyBatis 映射到 Java 的 int 字段时，数据库返回 NULL，JDBC 驱动无法把 SQL 的 NULL 转成基本类型，抛出类似 Cannot set property 'score' of null 的异常。
- Java 实体中用了基本类型（
int、long）而非包装类（Integer、Long） - MyBatis 或 Hibernate 没配置自动将 NULL 映射为默认值（如 0）
- MySQL 开启了
STRICT_TRANS_TABLES，且你在 INSERT/UPDATE 中用到了该 NULL 结果
IFNULL 和 COALESCE 在聚合前还是聚合后用？
必须在聚合「之前」处理 NULL，否则 SUM(NULL) 还是 NULL，AVG(NULL) 也是 NULL；但更关键的是：如果原始字段是 NULL，SUM 会直接忽略它——这本身没错，可一旦你期望“没订单就显示 0”，就得提前兜底。
-
IFNULL(score, 0)→ 把每行 score 的 NULL 替换成 0，再进SUM，结果才可能是非 NULL -
SUM(IFNULL(score, 0))安全；SUM(score)在 score 全为 NULL 时返回NULL - MySQL 用户优先用
IFNULL（两参数、快）；跨库或需多级兜底时用COALESCE(score, 0)或COALESCE(score, alias, 'guest')
WHERE 里写右表条件，会让 LEFT JOIN 变成 INNER JOIN
这个坑比 NULL 更隐蔽：你以为在查“所有用户及其订单总额”，结果只返回了有订单的用户。
- 错误写法：
SELECT u.name, SUM(o.amount) FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'→o.status为 NULL 的行被 WHERE 干掉，LEFT JOIN 失效 - 正确写法：
SELECT u.name, SUM(o.amount) FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'→ 条件放进ON，保留左表全部用户，无匹配则o.amount为 NULL，SUM自动跳过 - 若还需区分“有订单但非 paid”和“完全无订单”，得靠
CASE WHEN o.status IS NULL THEN 'no_order' ...
聚合结果仍是 NULL？检查分组和连接膨胀
就算用了 IFNULL，SUM 结果还为 NULL，大概率是 GROUP BY 错了，或 LEFT JOIN 引入了意外的空行。
- 确认
GROUP BY字段是否包含所有非聚合列，漏掉会导致隐式分组，结果不可控 - 执行不带聚合的原始 LEFT JOIN，加
LIMIT 10看实际数据：是否某用户关联了 0 行订单（此时o.amount全为 NULL），那SUM就是 NULL —— 这时才真该用COALESCE(SUM(IFNULL(o.amount, 0)), 0) - Hive 或 Spark SQL 中，
LEFT JOIN右表为空可能触发元数据缺失错误（如Table not found），和 NULL 无关，得先确认表存在且可读
最常被忽略的一点：NULL 不是“空字符串”也不是“0”，它是未知值；三值逻辑下，NULL = NULL 返回 UNKNOWN，不是 TRUE。所以用 COALESCE 或 IFNULL 填充，不只是为了好看或防报错，更是为了把“未知”转成业务可解释的“默认”。
