COUNT(列名)忽略子查询返回的NULL，导致统计结果偏少；NOT IN遇NULL恒为UNKNOWN使结果为0；COUNT(DISTINCT (子查询))无法解决多行报错；GROUP BY中未关联分组键的子查询会引发统计错乱。
子查询返回NULL时，COUNT(列名)直接跳过整行
标量子查询没结果，数据库会静默转成NULL，而COUNT(列名)只统计非NULL值——这意味着外层COUNT根本看不到那行。比如：SELECT COUNT((SELECT name FROM users WHERE id = orders.user_id)) FROM orders，只要某条订单的user_id在users表里不存在，对应子查询就返回NULL，这行就被COUNT彻底忽略。
这不是报错，是安静失效。更危险的是，你查COUNT(*)和COUNT(子查询)结果不一致，却找不到明显错误提示。
- 别用
COUNT(子查询)，改用COUNT(*)配合LEFT JOIN显式关联 - 若必须保留子查询结构，至少用
COUNT(COALESCE((SELECT ...), 'dummy'))兜底（但性能差，仅临时调试） - 执行前先单独跑一遍子查询，确认是否真有
NULL返回
NOT IN + 子查询含NULL导致COUNT结果为0
NOT IN遇到子查询结果里有任意一个NULL，整个条件恒为UNKNOWN，所有行都被过滤掉——COUNT(*)自然变成0。例如：SELECT COUNT(*) FROM products WHERE id NOT IN (SELECT product_id FROM disabled WHERE reason IS NULL)，哪怕只有一条reason是NULL，整张products表都查不到。
- 永远不要依赖
NOT IN处理可能含NULL的子查询 - 安全写法是加过滤：
NOT IN (SELECT product_id FROM disabled WHERE product_id IS NOT NULL) - 推荐直接换
NOT EXISTS：NOT EXISTS (SELECT 1 FROM disabled d WHERE d.product_id = p.id)，它对NULL免疫
COUNT(DISTINCT ...)在子查询中被误当成去重救急手段
有人试图用COUNT(DISTINCT (SELECT ...))来“避免多行报错”，但DISTINCT不减少子查询行数——它只对最终结果集去重。而标量子查询上下文要求单值，DISTINCT根本进不了那一步，数据库早在执行子查询时就已报Subquery returns more than 1 row。
真正要解决多行问题，得回到业务意图：是匹配多个？用IN；是判断存在？用EXISTS；是取聚合值？用MAX()或AVG()包裹子查询。
-
COUNT(DISTINCT ...)只在聚合后结果集层面生效，不干预子查询执行逻辑 - 子查询本身返回多行 → 报错；返回0行 → 变
NULL；返回1行 → 正常。中间没有DISTINCT插手的空间 - 如果子查询本该唯一却因
JOIN膨胀出重复，才轮到DISTINCT出场
GROUP BY中嵌套子查询让COUNT分母变模糊
当COUNT出现在带GROUP BY的查询里，而子查询又没正确关联分组键时，COUNT统计范围会错乱。例如：SELECT dept, COUNT((SELECT COUNT(*) FROM logs l WHERE l.user_id = u.id)) FROM users u GROUP BY dept，子查询没绑定dept，每组都查全表logs，导致各dept的计数值相同甚至爆炸式增长。
- 检查子查询是否引用了
GROUP BY字段，没引用就大概率是全局扫描 - 把子查询提到
FROM子句，用LEFT JOIN预聚合，再GROUP BY - 用窗口函数替代，如
COUNT(*) OVER (PARTITION BY dept)，语义更清晰
NULL不是异常，是默认行为；它不报错、不警告，只悄悄让COUNT漏掉数据。最稳妥的做法，是把标量子查询从SELECT或WHERE里移出来，改用JOIN显式控制关联与空值处理边界。 
