LEFT JOIN 后不能用 HAVING 筛未完成任务，因其作用于分组后结果，无法识别右表缺失；正确做法是 WHERE 右表外键 IS NULL。
LEFT JOIN 后不能直接用 HAVING 筛未完成任务
直接在 LEFT JOIN 后加 HAVING 想找“没匹配到右表记录”的行，基本无效——HAVING 是对分组后的结果过滤，而未匹配的左表行本身不会被丢弃，但右表字段全为 NULL，它不参与聚合计算，也没法靠 HAVING 抓出来。
正确做法：用 WHERE 判断右表主键是否为 NULL
“未完成任务”通常指左表（如 tasks）存在，但右表（如 task_completions）无对应记录。关键不是聚合，而是识别 RIGHT 侧缺失。必须把判断逻辑放在 WHERE 子句，且确保写在 GROUP BY 之前（如果用了 GROUP BY）。
常见错误写法：HAVING COUNT(t2.id) = 0 —— 这只在你已按左表分组、且右表有行时才可能生效；若右表完全没关联行，COUNT 就是 0，但此时整行仍在结果中，HAVING 并不阻止它出现，反而可能因没 GROUP BY 直接报错。
- 先
LEFT JOIN task_completions t2 ON t1.id = t2.task_id - 再
WHERE t2.task_id IS NULL（用右表外键字段判NULL，比用t2.id更安全，避免右表自身主键允许NULL的边缘情况） - 如果确实需要聚合（比如统计每个用户未完成数），再补
GROUP BY t1.user_id，但筛选仍靠WHERE，不是HAVING
为什么不用 HAVING COUNT(...) = 0？
因为 HAVING 只能过滤已形成的分组，而“未完成”本质是连接态缺失，不是聚合值异常。举个例子：
SELECT t1.id, COUNT(t2.id) cnt FROM tasks t1 LEFT JOIN task_completions t2 ON t1.id = t2.task_id GROUP BY t1.id;
这条语句每行都有一条 t1.id 对应的记录，哪怕 t2.id 全是 NULL，COUNT(t2.id) 也是 0，HAVING cnt = 0 看似可行——但它多绕一层，且一旦你漏写 GROUP BY t1.id，语句就非法；而 WHERE t2.task_id IS NULL 直接、明确、无需分组也能用。
-
HAVING依赖GROUP BY，没分组时多数数据库直接报错 - 即使分了组，
COUNT统计的是非NULL值，对全NULL行返回 0，但这个 0 是计算结果，不是原始连接状态 -
WHERE t2.task_id IS NULL在连接后立刻过滤，执行计划更优，也更容易被索引利用
带业务条件的典型写法
比如查“用户 ID 为 123 且尚未提交审核的任务”：
SELECT t1.* FROM tasks t1 LEFT JOIN task_submissions t2 ON t1.id = t2.task_id AND t2.status = 'pending' WHERE t1.user_id = 123 AND t2.task_id IS NULL;
注意 t2.status = 'pending' 写在 ON 而非 WHERE：这是 LEFT JOIN 的关键技巧。如果把它挪到 WHERE，会把所有 t2.task_id 为 NULL 的行过滤掉（因为 NULL = 'pending' 不成立），导致结果为空。
-
ON中的条件控制“什么算匹配”，影响连接结果 -
WHERE中的条件是对连接结果整体过滤 - 要找“某类关联不存在”，就把业务约束放进
ON，再用WHERE ... IS NULL抓空档
真正容易被忽略的是 ON 和 WHERE 的语义差异——写错位置，结果就彻底跑偏。
