先说一个新手最容易踩的坑：WHERE 条件里不能直接引用列别名。
你写了一个带 COUNT(*) 的子查询，然后想在外层用 t.countB + t.countC + t.countD > 0 把全零的行过滤掉。这个思路本身没问题——但关键在于，这个求和表达式必须出现在外层的 WHERE 里，绝不能写成内层的别名。SQL 的执行顺序是铁律：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。SELECT 里定义的列别名（比如 countB），在同层的 WHERE 里根本不可见。
常见的错误场景：
- 写成
SELECT ..., (SELECT COUNT(*) ...) AS countB FROM a WHERE countB > 0→ 立刻报错Unknown column 'countB' in 'where clause' - 或者条件放到了
HAVING里，但没加GROUP BY→ 语法错误随之而来
那怎么办？两个选择：
- 把整个子查询包一层，让别名“落地”，再在外层
WHERE里做求和计算 - 或者简单场景下，直接用
EXISTS或CASE WHEN避免产生全零行
SQL中多个 COUNT(*) 字段同时为 0 怎么判断？过滤全零行的实用方法
当字段来自子查询（比如 (SELECT COUNT(*) FROM b WHERE b.id = a.bid) AS countB），它们天生就是数值，直接用 countB + countC + countD > 0 是最直观也最通用的写法。不过有几个坑需要留意：
- 如果任意一个子查询返回
NULL（关联表没有匹配记录），整行求和结果就是NULL，而NULL > 0永远为假——该行会被意外剔除 - 解法很简单：统一用
COALESCE(countB, 0)包一下，确保参与计算的每个数都是数字 - 千万别写成
countB != 0 AND countC != 0 AND countD != 0——这意思是“全部非零”，不是“非全零”，逻辑完全相反
修正后的写法：
SELECT t.* FROM (
SELECT
a.name,
COALESCE((SELECT COUNT(*) FROM b WHERE b.id = a.bid), 0) AS countB,
COALESCE((SELECT COUNT(*) FROM c WHERE c.id = a.cid), 0) AS countC,
COALESCE((SELECT COUNT(*) FROM d WHERE d.id = a.did), 0) AS countD
FROM a
) t WHERE (t.countB + t.countC + t.countD) > 0;
字段本身是数值型，如何过滤掉所有值为0的行？SQL条件写法与NULL处理
比如表里有 sales、profit、cost 三列，你要剔除的是这三列同时为 0 的行，而不是只要有一个是 0 就剔除。
这时候别用 sales != 0 AND profit != 0 AND cost != 0，那是“全非零”。正确思路是用否定形式：
NOT (sales = 0 AND profit = 0 AND cost = 0)- 或者等价写法：
sales != 0 OR profit != 0 OR cost != 0
还有一点容易被忽略：如果字段允许 NULL，= 0 不会匹配 NULL，但 != 0 也不会匹配 NULL ——所以 NULL 行默认会被保留。如果需要排除 NULL，就得显式写 sales IS NOT NULL AND profit IS NOT NULL AND cost IS NOT NULL。至于 != 和 <>，MySQL 里两者等价，但某些老版本对 != 支持不稳定，建议统一用 <>。
性能敏感时，别在 WHERE 里算聚合和子查询：SQL子查询性能优化技巧
上面那些嵌套子查询加外层求和的写法，在数据量一大就会明显变慢——每行都要执行三次独立子查询，那叫一个酸爽。
更高效的做法是“提前聚合”：先用 LEFT JOIN + COUNT() 配合 GROUP BY，对 b、c、d 各自按关联字段汇总计数，再和主表 a 左连接，避免重复计算。最后在 HAVING 或外层 WHERE 过滤。
关键在于：子查询写在 SELECT 列中，执行次数是 N×M；而预聚合加 JOIN 是 O(N+M) 级别。线上千万级表，性能差距可能高达百倍。
实际工作中，最容易被坑的两点就是 NULL 参与算术运算导致整行消失，以及子查询别名在同层 WHERE 不可见——可以说，这类问题七成以上的调试时间都耗在这两个地方。记住它们，少走不少弯路。
