sum(1)能当count()用是因为它对每行生成常量1后求和，数值结果等于行数；但语义错位、不处理null安全、非标准且易引发误解，count(*)才是正确选择。
为什么 SUM(1) 能当 COUNT() 用？
SUM(1) 统计行数本质是“对每行生成一个常量 1，再求和”，结果确实等于行数，但它的行为依赖于是否过滤 NULL —— SUM() 会自动忽略 NULL 值，而 COUNT() 不会（COUNT(*) 统所有行，COUNT(expr) 才跳 NULL）。所以用 SUM(1) 前必须确保没有 NULL 干扰，否则结果可能少于实际匹配行数。
常见错误现象：SUM(1) 在含 LEFT JOIN 且右表字段为 NULL 的场景下，若误写成 SUM(right_table.id)（而非 SUM(1)），就会漏计左表无匹配的行。
- 只在 WHERE 或 ON 条件已明确过滤掉 NULL 时才安全使用
SUM(1) - 想统计“满足某条件的行数”时，更推荐用
COUNT(CASE WHEN ... THEN 1 END)，语义清晰且 NULL 安全 -
SUM(1)和COUNT(*)在单表无 NULL 场景下性能几乎一致，但优化器不一定总能等价重写
SUM(CASE WHEN ...) 是更可靠的条件计数方式
直接用 SUM(1) 无法表达“仅对部分行计数”，必须配合 CASE WHEN。例如统计 status = 'active' 的用户数：
SELECT SUM(CASE WHEN status = 'active' THEN 1 ELSE 0 END) AS active_count FROM users;
注意：ELSE 0 很关键 —— 如果写成 ELSE NULL 或省略 ELSE，SUM() 会跳过这些行，导致结果偏小。
- 必须显式写
ELSE 0，不能依赖默认行为 -
COUNT(CASE WHEN status = 'active' THEN 1 END)效果相同，且更贴近语义（因为COUNT对非 NULL 计数） - 在 GROUP BY 查询中，
SUM(CASE ...)和COUNT(CASE ...)都可，但后者更易被团队理解
在 GROUP BY 中混用 SUM(1) 和条件聚合容易出错
有人试图这样写：SELECT dept, SUM(1), SUM(CASE WHEN salary > 5000 THEN 1 ELSE 0 END) FROM emp GROUP BY dept。表面看没问题，但隐患在于：如果某部门所有员工 salary 都 ≤ 5000，SUM(CASE ...) 返回 0，这没问题；但如果 WHERE 先过滤了某些行（比如加了 WHERE hire_date > '2020-01-01'），而 SUM(1) 和条件 SUM 的过滤逻辑不一致，就可能造成分母/分子错位。
- 确保所有聚合基于同一数据子集 —— 条件应统一放在 WHERE，或统一用 CASE 内置逻辑
- 避免在一个查询里既用 WHERE 过滤，又在 SUM(CASE) 里重复判断同一条件
- MySQL 8.0+ 和 PostgreSQL 支持
FILTER子句（如COUNT(*) FILTER (WHERE status='active')），语义最干净，但兼容性有限
NULL 值和空字符串陷阱必须手动处理
字符串字段常有空字符串 '' 或 NULL 混存。比如想统计非空邮箱数，写成 SUM(CASE WHEN email != '' THEN 1 ELSE 0 END) 会漏掉 NULL 行 —— 因为 email != '' 在 email 为 NULL 时结果是 UNKNOWN，进入 ELSE 分支得 0，这部分没被漏，但如果你误用了 SUM(email IS NOT NULL AND email != '')，那没问题；可一旦写成 SUM(CASE WHEN email THEN 1 ELSE 0 END)，就错了：NULL 参与布尔判断结果是 UNKNOWN，不进 THEN。
- 字符串非空判断务必拆开：
email IS NOT NULL AND TRIM(email) != '' - 数值字段要防 0 和 NULL 混淆，比如
amount > 0不等于amount IS NOT NULL - 用
COALESCE(email, '') != ''更简洁，但需确认数据库对 COALESCE 的 NULL 处理一致
SUM(1) 本身不是问题，真正复杂的是条件边界、NULL 传播路径和多层嵌套时的逻辑耦合 —— 看似一行代码，背后可能连着三张表的 NULL 策略。
