PostgreSQL中NOT IN子句导致DAU统计结果异常的问题排查

哎，这个坑我踩过好多次！NOT IN和IN的核心差异偏偏就在NULL的处理上，这正是你统计结果异常的根源。咱们一步步拆解：

1. IN 和 NOT IN 的工作机制差在哪？ #

IN 子句的逻辑 #

user_id IN (子查询) 本质是做OR逻辑的等于匹配：

user_id = 值1 OR user_id = 值2 OR ... OR user_id = 值N

这里有个关键细节：

• 如果子查询里混有NULL，user_id = NULL的结果是UNKNOWN，但只要有其他值匹配，整个表达式还是TRUE；
• 如果user_id本身是NULL，那么NULL = 任何值都是UNKNOWN，这种行会被WHERE直接过滤掉（因为WHERE只保留结果为TRUE的行）。

NOT IN 子句的逻辑 #

user_id NOT IN (子查询) 则是做AND逻辑的不等于匹配：

user_id != 值1 AND user_id != 值2 AND ... AND user_id != 值N

这就是坑的起点：

• 只要子查询里存在任何NULL值，user_id != NULL的结果就是UNKNOWN。而AND逻辑里只要有一个UNKNOWN，整个表达式的结果就是UNKNOWN，会被WHERE过滤？不对，你的情况是结果变多，大概率是这两个原因：要么你的non_users表中id的过滤不彻底（比如有空字符串而非NULL的情况），要么你现在的统计范围比之前的IN查询大——之前的IN是只包含「有username和position的真实用户」，现在的NOT IN只是排除non_users，那些没在non_users里但也不是真实用户的账号就被统计进来了。

2. 怎么修复你的DAU查询？ #

推荐用两种更可靠的方式替代NOT IN，彻底避开NULL陷阱：

方法一：用 NOT EXISTS（最推荐） #

NOT EXISTS的逻辑是「检查子查询是否存在匹配」，它对NULL的处理更友好，不会出现逻辑失效的情况：

SELECT count(distinct e.user_id) AS daily, e.event_timestamp::DATE AS date 
FROM "public"."events" AS e 
WHERE NOT EXISTS (
    SELECT 1 
    FROM "public"."non_users" AS nu 
    WHERE nu.id = e.user_id
)
GROUP BY date 
ORDER BY date

哪怕nu.id是NULL，nu.id = e.user_id会返回UNKNOWN，NOT EXISTS会把这种情况当作「不存在匹配」，完全不影响结果。

方法二：用 LEFT JOIN + IS NULL #

这也是避免NOT IN问题的经典写法，执行效率有时候还会更高：

SELECT count(distinct e.user_id) AS daily, e.event_timestamp::DATE AS date 
FROM "public"."events" AS e 
LEFT JOIN "public"."non_users" AS nu ON e.user_id = nu.id
WHERE nu.id IS NULL
GROUP BY date 
ORDER BY date

左连接后筛选未匹配的行，逻辑直观，也不会被NULL干扰。

方法三：硬扛NOT IN（不推荐，太脆弱） #

如果你非要用NOT IN，必须双管齐下：

• 确保子查询里绝对没有NULL；
• 同时过滤掉events表中user_id为NULL的行（因为NULL NOT IN (...)的结果是UNKNOWN，会被WHERE排除，但你之前的IN查询本来就没统计这些行）：

SELECT count(distinct e.user_id) AS daily, e.event_timestamp::DATE AS date 
FROM "public"."events" AS e 
WHERE e.user_id IS NOT NULL 
  AND e.user_id NOT IN (
      SELECT distinct id 
      FROM "public"."non_users" 
      WHERE id IS NOT NULL
)
GROUP BY date 
ORDER BY date

但这种方式太脆弱，哪天数据里出现新的NULL或者空字符串，又会出问题。

3. 额外提醒：和之前的IN查询对齐需求 #

你之前的IN查询是只统计「有username和position的真实用户」，现在的NOT IN只是排除non_users。如果你的需求是和之前完全一致（即只统计真实用户，排除员工、Beta测试等），那应该把两个条件结合起来，或者确保non_users表包含所有非真实用户，否则统计范围变大，DAU自然会比之前高。

内容的提问来源于stack exchange，提问作者Hannes