【SQL】NOT IN 遇到 NULL 为什么返回空集？三值逻辑与反关联实战

【SQL】NOT IN 遇到 NULL 为什么返回空集？三值逻辑与反关联实战

有一条"找出从未下过单的用户"的 SQL，测试环境返回几十行，上线后却突然变成 0 行。用户表有数据、订单子查询也有数据，执行计划看起来正常，问题可能只藏在一条订单的 user_id IS NULL。NOT IN 的结果不是简单的"左边不在右边集合里"：只要匹配失败但候选集合里有 NULL，比较结果就可能是 UNKNOWN，WHERE 会把它过滤掉。本文用 SQLite 自带的 Python 驱动构造最小复现，再给出何时选 NOT EXISTS、何时保留 NOT IN，以及怎样避免改写时意外改变 NULL 语义。

1. 三行用户，复现空结果

数据库用 Python 标准库 SQLite，保存为 not_in_null_demo.py：

import sqlite3

db = sqlite3.connect(":memory:")
db.executescript("""
CREATE TABLE users(id INTEGER PRIMARY KEY, name TEXT NOT NULL);
CREATE TABLE orders(id INTEGER PRIMARY KEY, user_id INTEGER NULL);
INSERT INTO users(id, name) VALUES (1, 'Ada'), (2, 'Linus'), (3, 'Grace');
INSERT INTO orders(id, user_id) VALUES (10, 1), (11, NULL);
""")

sql = "SELECT id, name FROM users WHERE id NOT IN (SELECT user_id FROM orders) ORDER BY id"
print(db.execute(sql).fetchall())

[]

如果删除订单表中的 NULL 行，相同查询返回 [(2, 'Linus'), (3, 'Grace')]。变化只来自候选集多了一个未知值。这里没有数据丢失，也不是 NOT IN 的数据库 bug，而是 SQL 对 NULL 的比较语义。下图 展示候选值全部非空和混入 NULL 时的逻辑差别。

实验结果：SQLite 原写法、修正写法与边界输入的真实输出。

2. WHERE 为什么只接受 TRUE

在普通二值逻辑里，"2 不等于 1"是 TRUE。但 2 <> NULL 无法得到真或假，因为 NULL 表示缺失或未知，而不是某个可比较的普通值；结果是 UNKNOWN（SQL 通常以 NULL 表示）。NOT IN 等价于多个比较结果的合取：

2 NOT IN (1, 3)       -- TRUE
2 NOT IN (1, NULL)    -- UNKNOWN
2 NOT IN (2, NULL)    -- FALSE（存在明确匹配）

最后一种仍然是 FALSE，因为命中 2 已足以否定"不在集合中"。第二种情况里，数据库既不能证明候选集全都不等于 2，也找不到相等项，因此答案未知。WHERE 仅保留 TRUE；FALSE 和 UNKNOWN 都不进入结果。于是子查询中一个 NULL 足以让所有"未命中"的候选行落入 UNKNOWN。

这也解释为什么 NOT IN 的问题不是"NULL 本身被返回/过滤"这么简单，而是 NULL 参与了否定匹配的逻辑判断。SQLite 官方文档列出了 IN / NOT IN 的结果矩阵；MySQL 手册也指出，只要没有匹配且候选项有 NULL，IN 可返回 NULL，NOT IN 是它的逻辑取反，仍为 NULL。

教学示意：TRUE、UNKNOWN、FALSE 进入 WHERE 的区别。

3. 按业务含义选择反关联写法

默认优先考虑 NOT EXISTS，但要先说清业务含义

"找出没有任何匹配订单的用户"是相关存在性判断：

SELECT u.id, u.name
FROM users AS u
WHERE NOT EXISTS (
    SELECT 1
    FROM orders AS o
    WHERE o.user_id = u.id
)
ORDER BY u.id;

在示例数据中返回 Linus 和 Grace。EXISTS 只关心子查询是否至少返回一行，行里的关联列值是不是 NULL，不会作为 EXISTS 自身的真假结果；连接条件 o.user_id = u.id 对 NULL 产生 UNKNOWN，不满足条件，因此该行不构成匹配。这个写法表达的是"没有一条满足等值关系的订单"，通常更贴近业务原意。

但"永远用 NOT EXISTS"也不严谨。若左侧 u.id 允许为 NULL，NOT EXISTS (o.key = u.key) 会把左侧 NULL 行视为没有等值匹配而保留；而 NULL NOT IN (...) 结果通常是 UNKNOWN，反而被过滤。两种写法只有在键列的 NULL 约束和业务定义一致时才等价。应先回答：左值为空代表"未知用户"、应该保留还是应该排除？再写 SQL。

三种修正方案，以及什么时候选哪一种

**方案 A：业务键不允许 NULL，且子查询数据可能脏。**可在子查询显式过滤：

SELECT u.id, u.name
FROM users AS u
WHERE u.id NOT IN (
    SELECT o.user_id FROM orders AS o WHERE o.user_id IS NOT NULL
);

如果左侧键也可空，应额外明示策略，例如 u.id IS NOT NULL AND ...。不能假定过滤右侧就自动解决左值 NULL。

**方案 B：询问是否存在关联记录。**用 NOT EXISTS：它天然避免右侧无关 NULL 把整组候选全部变 UNKNOWN，且方便组合额外条件，例如"没有已完成订单"：

WHERE NOT EXISTS (
    SELECT 1 FROM orders o
    WHERE o.user_id = u.id AND o.status = 'completed'
)

方案 C：外连接反连接。

SELECT u.id, u.name
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE o.id IS NULL;

判断未匹配列要选右表保证非 NULL 的主键 o.id，不能随手选择一个可空业务列：匹配到了但该列本来就是 NULL，也会被误当作未匹配。如果连接条件上还有右表过滤条件，放在 ON 还是 WHERE 会影响语义，需要通过小数据集验证。
#mermaid-svg-M4NRXflvwLGoKEzC{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-M4NRXflvwLGoKEzC .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-M4NRXflvwLGoKEzC .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-M4NRXflvwLGoKEzC .error-icon{fill:#552222;}#mermaid-svg-M4NRXflvwLGoKEzC .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-M4NRXflvwLGoKEzC .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-M4NRXflvwLGoKEzC .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-M4NRXflvwLGoKEzC .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-M4NRXflvwLGoKEzC .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-M4NRXflvwLGoKEzC .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-M4NRXflvwLGoKEzC .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-M4NRXflvwLGoKEzC .marker{fill:#333333;stroke:#333333;}#mermaid-svg-M4NRXflvwLGoKEzC .marker.cross{stroke:#333333;}#mermaid-svg-M4NRXflvwLGoKEzC svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-M4NRXflvwLGoKEzC p{margin:0;}#mermaid-svg-M4NRXflvwLGoKEzC .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-M4NRXflvwLGoKEzC .cluster-label text{fill:#333;}#mermaid-svg-M4NRXflvwLGoKEzC .cluster-label span{color:#333;}#mermaid-svg-M4NRXflvwLGoKEzC .cluster-label span p{background-color:transparent;}#mermaid-svg-M4NRXflvwLGoKEzC .label text,#mermaid-svg-M4NRXflvwLGoKEzC span{fill:#333;color:#333;}#mermaid-svg-M4NRXflvwLGoKEzC .node rect,#mermaid-svg-M4NRXflvwLGoKEzC .node circle,#mermaid-svg-M4NRXflvwLGoKEzC .node ellipse,#mermaid-svg-M4NRXflvwLGoKEzC .node polygon,#mermaid-svg-M4NRXflvwLGoKEzC .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-M4NRXflvwLGoKEzC .rough-node .label text,#mermaid-svg-M4NRXflvwLGoKEzC .node .label text,#mermaid-svg-M4NRXflvwLGoKEzC .image-shape .label,#mermaid-svg-M4NRXflvwLGoKEzC .icon-shape .label{text-anchor:middle;}#mermaid-svg-M4NRXflvwLGoKEzC .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-M4NRXflvwLGoKEzC .rough-node .label,#mermaid-svg-M4NRXflvwLGoKEzC .node .label,#mermaid-svg-M4NRXflvwLGoKEzC .image-shape .label,#mermaid-svg-M4NRXflvwLGoKEzC .icon-shape .label{text-align:center;}#mermaid-svg-M4NRXflvwLGoKEzC .node.clickable{cursor:pointer;}#mermaid-svg-M4NRXflvwLGoKEzC .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-M4NRXflvwLGoKEzC .arrowheadPath{fill:#333333;}#mermaid-svg-M4NRXflvwLGoKEzC .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-M4NRXflvwLGoKEzC .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-M4NRXflvwLGoKEzC .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-M4NRXflvwLGoKEzC .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-M4NRXflvwLGoKEzC .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-M4NRXflvwLGoKEzC .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-M4NRXflvwLGoKEzC .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-M4NRXflvwLGoKEzC .cluster text{fill:#333;}#mermaid-svg-M4NRXflvwLGoKEzC .cluster span{color:#333;}#mermaid-svg-M4NRXflvwLGoKEzC div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-M4NRXflvwLGoKEzC .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-M4NRXflvwLGoKEzC rect.text{fill:none;stroke-width:0;}#mermaid-svg-M4NRXflvwLGoKEzC .icon-shape,#mermaid-svg-M4NRXflvwLGoKEzC .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-M4NRXflvwLGoKEzC .icon-shape p,#mermaid-svg-M4NRXflvwLGoKEzC .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-M4NRXflvwLGoKEzC .icon-shape .label rect,#mermaid-svg-M4NRXflvwLGoKEzC .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-M4NRXflvwLGoKEzC .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-M4NRXflvwLGoKEzC .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-M4NRXflvwLGoKEzC :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 有
无
当前用户 id 为 2
子查询尝试匹配 user_id = 2
有满足条件的订单行？
EXISTS 为真：不保留用户
NOT EXISTS 为真：保留用户

判断流程：NOT EXISTS 检查是否有满足关联条件的订单行。

4. 左侧 NULL 与空子查询的边界

可运行实验：把三种改写的输出并排看

在脚本中追加：

queries = {
    "NOT IN 原写法": """
        SELECT u.id FROM users u
        WHERE u.id NOT IN (SELECT o.user_id FROM orders o) ORDER BY u.id
    """,
    "NOT IN 过滤右侧 NULL": """
        SELECT u.id FROM users u
        WHERE u.id NOT IN (SELECT o.user_id FROM orders o WHERE o.user_id IS NOT NULL)
        ORDER BY u.id
    """,
    "NOT EXISTS": """
        SELECT u.id FROM users u
        WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)
        ORDER BY u.id
    """,
}
for label, query in queries.items():
    print(label, db.execute(query).fetchall())

预期输出：

NOT IN 原写法 []
NOT IN 过滤右侧 NULL [(2,), (3,)]
NOT EXISTS [(2,), (3,)]

示例 schema 把 users.id 定义成主键，SQLite 会自动保证它非 NULL；要验证"左侧键可空"的边界，应另建允许空值的键列，而不是往主键塞 NULL：

CREATE TABLE external_users(user_key TEXT NULL, name TEXT NOT NULL);
INSERT INTO external_users VALUES (NULL, 'Unknown');

对 external_users.user_key 分别运行过滤 NULL 的 NOT IN 与 NOT EXISTS，会发现左值 NULL 的语义也可能不同。这样的反例是改写 SQL 的必要测试，不是边缘噪音。真实系统里尽量使用非空主键做关联；若业务确实有未知键行，应在输出前显式决定保留、排除或单独统计。

空子查询也是一个应单测的边界

当右侧子查询没有任何行时，非空键的 NOT IN 为 TRUE；这对批处理启动、分区无数据或过滤条件过严都很关键。若你动态拼接筛选条件，某次参数让子查询变空，结果可能从正常名单变成全部候选行。上线前应验证空集是否意味着"全部未匹配"还是"暂时无权计算"；权限敏感查询通常要避免将意外空子查询当作放行依据。

把左侧空值和空子查询实际跑出来

下面是一个与用户主键分开的边界实验。保存为 sql_boundaries.py 并执行。字段没有非空约束，因此能明确构造左键为 NULL 的行，而不是往 INTEGER PRIMARY KEY 塞 NULL 后让 SQLite 自动分配编号。

import sqlite3
db = sqlite3.connect(":memory:")
db.executescript("CREATE TABLE a(k); CREATE TABLE b(k); INSERT INTO a VALUES(2),(NULL); INSERT INTO b VALUES(1);")
print("left NULL / NOT IN:", db.execute("SELECT k FROM a WHERE k NOT IN (SELECT k FROM b)").fetchall())
print("left NULL / NOT EXISTS:", db.execute("SELECT k FROM a WHERE NOT EXISTS (SELECT 1 FROM b WHERE b.k=a.k)").fetchall())
db.execute("DELETE FROM b")
print("empty right / NOT IN:", db.execute("SELECT k FROM a WHERE k NOT IN (SELECT k FROM b)").fetchall())
print("truth matrix:", db.execute("SELECT 2 NOT IN (1,3), 2 NOT IN (1,NULL), 2 NOT IN (2,NULL)").fetchone())

实际输出先是左侧 NOT IN 仅留下二，NOT EXISTS 留下二和 NULL；清空右表后，NOT IN 也留下二和 NULL。最后的真假矩阵是 (1, None, 0)，分别对应 TRUE、UNKNOWN、FALSE。Python 把 SQL 的 NULL 显示成 None，这里并不是驱动异常，也不是 Python 布尔函数参与了比较。

对比图：右侧集合非空且不含 NULL 时，左侧空键仍使普通等值 NOT EXISTS 与 NOT IN 不同。

右表为空的结果看起来反直觉，因为平时的"NULL 比较未知"是在确实有比较对象时讨论的。空集合中不存在与左值比较的候选，SQLite 的 NOT IN 结果矩阵明确包括这个情况。对空子查询的语义与对字面量空括号的语法接受，要分开测试；不同引擎不一定接受 IN 后面直接写空括号。

5. LEFT JOIN 的判定列与条件位置

建立反连接时，选一个右表主键作 NULL 判定，并把右表限制条件放在正确位置：

SELECT u.id
FROM users AS u
LEFT JOIN orders AS o
  ON o.user_id = u.id
 AND o.status = 'completed'
WHERE o.id IS NULL;

这段含义是"没有完成状态订单"，不是"没有任何订单"。如果把 o.status='completed' 移到 WHERE，未匹配行上 o.status 为 NULL，WHERE 会丢掉它们；外连接的保留效果被条件破坏。测试样例应包括：用户 A 只有未完成订单、用户 B 有完成订单、用户 C 没订单。预期 A/C 留下，B 被排除。这样可以防止将 NOT EXISTS 改成 JOIN 时只检查一条正常记录。

业务筛选还可能在关联键上使用转换，例如 CAST(o.user_id AS TEXT)=u.id。这会影响索引使用与类型语义，也可能让看似相同的键因前导零或排序规则被判为不同。先规范化数据类型和比较规则，再比较两种反连接写法；不要在查不到结果后无计划地套 CAST。

验证 LEFT JOIN 的判定列

可以另建一个带可空备注的订单小表，为一个用户插入编号有效、备注为空的订单，同时让另一个用户没有任何订单。连接后，两行备注都为空，但只有后者的订单主键为空。如果 WHERE 判断备注，就会错误留下已经有订单的用户；改为保证非空的订单主键，才能区分这两种状态。

图中的 Bob 与 Carol 是这个独立示意例子的名字，不是前面 Ada、Linus、Grace 实验的输出。图的职责是展示补 NULL 行与真实可空字段的差异，实际数据库结果仍以最前面的代码和证据图为准，不能用插画代替查询。

独立教学示意：已经匹配的订单可以备注为空，未匹配应通过非空主键识别。

6. 空结果的排查顺序与六个误区

排查"NOT IN 查不出数据"的顺序

第一步，确认主查询和子查询分别返回什么。把 NOT IN (subquery) 临时换成 SELECT DISTINCT key FROM ... 检查候选值；不要仅看表是否"有记录"。第二步，数出右侧 NULL：

SELECT COUNT(*) AS total_rows,
       SUM(CASE WHEN user_id IS NULL THEN 1 ELSE 0 END) AS null_rows
FROM orders;

第三步，逐个拿一个未命中主键跑 SELECT 42 NOT IN (1, NULL)，确认逻辑层面。第四步，检查左侧表达式是否也可能为 NULL、类型转换、字符排序规则或复合键对比较的影响。第五步，明确业务目标后改写为 NOT EXISTS、过滤 NULL 的 NOT IN 或 LEFT JOIN，最后用"有匹配/无匹配/右侧 NULL/左侧 NULL/重复候选"五类数据做回归。

不要先加 COALESCE(user_id, -1) 来消除 NULL。若 -1 可能是有效键就造成假匹配；即便约束保证不会冲突，也是在悄悄把未知值映射成一个真实值，掩盖数据质量问题。只有业务定义明确存在哨兵值，并且范围受约束时才可考虑。

五个常见误区

**误区一：NULL 等于空字符串或 0。**不成立。它代表未知/缺失；NULL = NULL 也不是 TRUE。测试空值用 IS NULL，不要用 = NULL。

**误区二：右侧含 NULL，就认为每次比较结果都是 UNKNOWN。**未命中的非空左值会得到 UNKNOWN；存在确切匹配的左值则得到 FALSE。在本文这种标量 WHERE key NOT IN (子查询) 中，两者都不能留下行，所以确实得到空集。解释时仍应区分 FALSE 与 UNKNOWN，不能把这个结论不加限定地外推到复合键或带其他 OR 条件的表达式。

**误区三：过滤子查询 NULL 后，两种写法完全相同。**若左值允许 NULL，仍可能不同。把左右键的可空约束和对 NULL 行的业务处理写明。

**误区四：NOT EXISTS 一定比 NOT IN 快。**性能取决于优化器、索引、数据分布、相关谓词和数据库版本。它通常是表达反关联的清晰方式，不代表无条件更快。用 EXPLAIN / EXPLAIN ANALYZE 对真实数据验证计划与实际行数。

**误区五：LEFT JOIN 后 WHERE right_table.some_nullable_col IS NULL 总能判断未匹配。**匹配到的行也可能该列为 NULL。选择右表非空主键，并确保 join 条件和额外筛选的位置符合目标。

**误区六：把 NULL 替成固定值就完事。**可能碰撞、改变排序或让优化器估算偏差；应该先修复数据约束，或选语义显式的查询。

7. 索引、执行计划与参数输入

索引、执行计划和数据库差异

对于 NOT EXISTS 的相关条件，常见索引起点是 orders(user_id)；如果还有 status 等过滤列，可以评估 (user_id, status) 顺序，但最终取决于选择性和其他查询负载。索引能减少查找成本，不能修复错误的 NULL 逻辑。小表全扫可能比索引访问更便宜；不要看到反连接就机械建索引。

SQLite、MySQL、PostgreSQL 等实现都遵循 NULL 逻辑，但类型系统、执行计划显示和特定语法细节不同。本文用 SQLite 验证逻辑，不将其运行耗时外推到 MySQL 生产环境。迁移时分别在目标数据库执行最小测试与 explain。若改写前后行数不同，优先比较 NULL 语义和重复匹配，而不是先怀疑索引。

安全方面，查询参数化与 NOT IN 的 NULL 问题是两件事：绑定参数能防 SQL 注入，不能让 NULL 自动变成预期语义。拼接用户提供的 ID 列表还要处理空列表，各数据库对 IN () 的语法接受度可能不同；更稳妥的是临时表/表值参数或受控的占位符生成，并明确空集合时应返回全部还是无结果。

性能验证不是比较 SQL 字符数

NOT EXISTS 子查询看起来每个用户都跑一次，但优化器可能把它转换为反连接算子；反过来，NOT IN 也可能需要物化或处理 NULL 标记。源码表述方式不直接等于物理执行次数。基准应至少覆盖：左侧行数、右侧行数、匹配率、NULL 比率、索引是否存在和缓存冷热。记录数据库版本、表统计信息、实际执行计划与耗时，区分估算行数和实际行数。

针对 orders.user_id 建索引后，NOT EXISTS 的等值探测可能受益；但右表很小或大多数用户都没有匹配时，优化器可能选择其他策略。复合索引的列顺序需结合该表其他查询，而不是只为这一篇 SQL。生产修改前应在同版本和近似数据量的副本上分析计划；本文本机 SQLite 输出只证明结果逻辑，不构成 MySQL、PostgreSQL 的性能结论。

8. 把可空约束与业务模型对齐

复合键的 NULL 不是"整行空值"

订单可能按租户和用户联合关联：租户列非空、用户列为空。此时 (tenant_id, user_id) 并非"完全没有数据"，而是一个部分未知的复合键。两个字段都参与等值 join 时，用户列比较结果为 UNKNOWN，整条匹配谓词不会成为 TRUE。业务可能希望这类记录归入"未匹配"，也可能认为它是数据错误，应在报表中单独列出。把全部未匹配行简单展示给运营人员，会混淆"确实没有订单"和"订单缺少关联字段"。

做反连接报表时，可以把缺失关联数据和业务上没有关联拆成两类指标：一列用 user_id IS NULL 统计脏/未归属订单，另一列用 NOT EXISTS 找出没有有效订单的用户。数据质量指标能揭示 NULL 来源，也避免业务层用过滤条件把问题悄悄隐藏。这个区分对权限查询同样重要：访问控制应采用明确的 fail-closed 逻辑，不能把"不知道所属用户"当成"所有人都可访问"。

数据模型先把可空性说清楚

很多"NOT IN 突然失效"的根因不是查询作者，而是列的可空约束与业务假设不一致。产品认为每一条订单都必须归属用户，但历史导入、删除用户后的脱敏或数据清洗流程留下了 user_id=NULL；如果列允许空，查询就必须处理这种现实。若业务确实规定订单必须关联用户，应检查数据后增加 NOT NULL 或外键约束，而不是永久在所有 SQL 里散布防御性过滤。约束可阻止脏值继续进入，查询仍需对已有历史数据迁移。

外键约束也不一定默认禁止 NULL。常见关系数据库允许可空外键以表示暂时未关联；这与"外键必须匹配父表"并不矛盾，因为 NULL 不指向某个父键。理解约束组合：NOT NULL 负责非空，外键负责非空值引用有效父行。若两者只配了后者，却在业务层假设外键永远非空，就会出现 NOT IN 陷阱。

批量清理前建议先量化 NULL 规模、来源和时间范围：按创建日期分组统计、抽样看产生路径、查导入任务是否跳过必填字段。确认没有数据后补约束；确认 NULL 合法则在每个业务查询里明确它对"不存在"的意义。不能仅凭 COUNT(*)=0 的一次查询就认定将来不会再有 NULL，线上写入路径也要一起修正。

用业务关联定义解释结果

如果需求是"找出没有任何有效关联记录的行"，把有效条件放进 NOT EXISTS 的相关子查询，往往最贴近句子。如果是对一个保证非空的键集合做反向成员测试，过滤右侧 NULL 的 NOT IN 也可以。决定前检查左右两边可空性、NULL 代表的业务含义、重复数据和空子查询行为。用四五行数据跑出反例，比在大表上盲目改 SQL 更快，也更安全。

给报表增加一个数据质量分支

找无订单用户的查询与统计无归属订单的查询，应成为两个不同的指标。前者在用户表上做反关联，后者在订单表上统计 user_id IS NULL；若把两者混合，运营会把未知归属订单误认为用户没有发生交易。可按来源、时间段和写入渠道检查空关联，从源头区分合法游客数据与导入遗漏。

关系图：NOT NULL 保证有关联编号，外键保证非空编号有效；可空外键不能代替非空约束。

调整非空约束时，先选择历史空值的迁移策略，再处理新写入。回填编号要有真实业务依据，不能为了通过约束给所有空订单填成同一个用户。SQLite 的外键检查还需按官方说明在连接上启用 PRAGMA foreign_keys，例子的内存表没有声明外键，不应误认为已经验证了生产数据完整性策略。
#mermaid-svg-hOMrDX46WIr27l0J{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-hOMrDX46WIr27l0J .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-hOMrDX46WIr27l0J .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-hOMrDX46WIr27l0J .error-icon{fill:#552222;}#mermaid-svg-hOMrDX46WIr27l0J .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-hOMrDX46WIr27l0J .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-hOMrDX46WIr27l0J .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-hOMrDX46WIr27l0J .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-hOMrDX46WIr27l0J .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-hOMrDX46WIr27l0J .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-hOMrDX46WIr27l0J .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-hOMrDX46WIr27l0J .marker{fill:#333333;stroke:#333333;}#mermaid-svg-hOMrDX46WIr27l0J .marker.cross{stroke:#333333;}#mermaid-svg-hOMrDX46WIr27l0J svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-hOMrDX46WIr27l0J p{margin:0;}#mermaid-svg-hOMrDX46WIr27l0J .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-hOMrDX46WIr27l0J .cluster-label text{fill:#333;}#mermaid-svg-hOMrDX46WIr27l0J .cluster-label span{color:#333;}#mermaid-svg-hOMrDX46WIr27l0J .cluster-label span p{background-color:transparent;}#mermaid-svg-hOMrDX46WIr27l0J .label text,#mermaid-svg-hOMrDX46WIr27l0J span{fill:#333;color:#333;}#mermaid-svg-hOMrDX46WIr27l0J .node rect,#mermaid-svg-hOMrDX46WIr27l0J .node circle,#mermaid-svg-hOMrDX46WIr27l0J .node ellipse,#mermaid-svg-hOMrDX46WIr27l0J .node polygon,#mermaid-svg-hOMrDX46WIr27l0J .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-hOMrDX46WIr27l0J .rough-node .label text,#mermaid-svg-hOMrDX46WIr27l0J .node .label text,#mermaid-svg-hOMrDX46WIr27l0J .image-shape .label,#mermaid-svg-hOMrDX46WIr27l0J .icon-shape .label{text-anchor:middle;}#mermaid-svg-hOMrDX46WIr27l0J .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-hOMrDX46WIr27l0J .rough-node .label,#mermaid-svg-hOMrDX46WIr27l0J .node .label,#mermaid-svg-hOMrDX46WIr27l0J .image-shape .label,#mermaid-svg-hOMrDX46WIr27l0J .icon-shape .label{text-align:center;}#mermaid-svg-hOMrDX46WIr27l0J .node.clickable{cursor:pointer;}#mermaid-svg-hOMrDX46WIr27l0J .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-hOMrDX46WIr27l0J .arrowheadPath{fill:#333333;}#mermaid-svg-hOMrDX46WIr27l0J .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-hOMrDX46WIr27l0J .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-hOMrDX46WIr27l0J .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-hOMrDX46WIr27l0J .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-hOMrDX46WIr27l0J .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-hOMrDX46WIr27l0J .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-hOMrDX46WIr27l0J .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-hOMrDX46WIr27l0J .cluster text{fill:#333;}#mermaid-svg-hOMrDX46WIr27l0J .cluster span{color:#333;}#mermaid-svg-hOMrDX46WIr27l0J div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-hOMrDX46WIr27l0J .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-hOMrDX46WIr27l0J rect.text{fill:none;stroke-width:0;}#mermaid-svg-hOMrDX46WIr27l0J .icon-shape,#mermaid-svg-hOMrDX46WIr27l0J .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-hOMrDX46WIr27l0J .icon-shape p,#mermaid-svg-hOMrDX46WIr27l0J .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-hOMrDX46WIr27l0J .icon-shape .label rect,#mermaid-svg-hOMrDX46WIr27l0J .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-hOMrDX46WIr27l0J .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-hOMrDX46WIr27l0J .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-hOMrDX46WIr27l0J :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 拆开查询，检查 NULL
定义有效关联条件
逐行对照改写结果
结果正确后检查执行计划

实践路线：先对照语义，再检查目标引擎执行计划。

参考资料

• SQLite Expressions
• SQLite Foreign Keys
• MySQL NULL
• MySQL Comparison