在 PostgreSQL 中，EXCLUDED 虚拟表代表在 ON CONFLICT 操作期间提议插入的行。历史上，从 MySQL 或 Oracle 环境迁移的开发人员通常会假设直接的相等比较 (=) 足以检测 upsert 模式中的值变化。然而，SQL 标准三值逻辑规定 NULL 代表一个未知状态，这意味着 NULL = NULL 评估为 NULL（未知），而不是 TRUE。
这在冲突解决子句尝试通过添加 WHERE 子句（例如 WHERE EXCLUDED.phone != users.phone）来优化更新时造成了一个关键问题。如果现有行和提议行的手机列都包含 NULL，则比较返回 NULL，这会使 WHERE 谓词失败。因此，尽管在业务逻辑的上下文中值可能真正不同，但数据库仍会跳过更新，因为它无法区分新数据中的 NULL 和旧数据中的 NULL。
解决方案是利用 IS DISTINCT FROM 运算符，它将 NULL 视为一个可比较的值。通过将更新子句构建为 WHERE EXCLUDED.column IS DISTINCT FROM table.column，当两个值都是 NULL 时，比较返回 FALSE（表示没有变化），而当一个是 NULL 而另一个不是时返回 TRUE。这确保了确定性行为，同时防止不必要的写入。
INSERT INTO patient_records (clinic_id, external_id, phone, updated_at) VALUES (101, 'P-2024-001', NULL, NOW()) ON CONFLICT (clinic_id, external_id) DO UPDATE SET phone = COALESCE(EXCLUDED.phone, patient_records.phone), updated_at = EXCLUDED.updated_at WHERE EXCLUDED.phone IS DISTINCT FROM patient_records.phone;
一个医院网络需要将来自 50 个外部诊所的每日患者接收数据同步到一个中央 PostgreSQL 数据仓库。每个诊所导出的 CSV 文件中缺少的患者电话号码表现为空字符串，这在导入时被 COPY 命令转换为 NULL。现有的 Python ETL 脚本使用 SQLAlchemy 执行批量 upsert，设置为 ON CONFLICT (clinic_id, external_id) DO UPDATE SET phone = EXCLUDED.phone。
问题出现在诊所员工报告说，直接输入到中央系统中的有效电话号码在夜间同步后神秘消失。调查发现，当外部馈送发送 NULL（表示未知的电话）时，它覆盖了现有的有效号码，因为 SET 子句无条件执行。添加一个简单的过滤器 WHERE EXCLUDED.phone != patient_records.phone 失败了，因为当两者都是 NULL 时，比较返回 NULL（未知），导致更新被错误跳过，当新值为 NULL 而旧值不是时，逻辑在不同的 PostgreSQL 次要版本中表现不一致。
评估了三种解决方案。
第一种方法在 SET 子句中专门使用 COALESCE：SET phone = COALESCE(EXCLUDED.phone, patient_records.phone)。这防止用 NULL 进行覆盖，但在每次冲突时强制更新，触发昂贵的 B-Tree 索引重建并触发审核触发器记录“无操作”更改为合法修改。这使 WAL （预写日志）流量增加了 300%，威胁到复制延迟并占满磁盘 I/O。
第二种解决方案尝试使用显式布尔逻辑处理 NULL：WHERE (EXCLUDED.phone != patient_records.phone) OR (EXCLUDED.phone IS NULL AND patient_records.phone IS NOT NULL)。虽然逻辑上正确，但这个冗长的模式需要在 15 个可空列上进行仔细维护，并混淆了查询优化器。规划器放弃了索引扫描，而选择了对 2000 万行表的顺序扫描，导致 ETL 作业超出六小时维护窗口。
第三种解决方案为 WHERE 子句中的所有可空列实现了 IS DISTINCT FROM。这提供了一个简洁、可索引的谓词，正确识别真正的数据变化，包括 NULL 转换。它仅在必要时允许更新，消除了多余的触发执行和 WAL 生成，同时保持一致的查询计划。
团队选择了第三种解决方案用于关键联系字段，第一种解决方案用于非关键元数据，其中覆盖保护比性能更重要。结果是显著的：同步作业的持续时间从 45 分钟下降到 12 分钟，复制延迟稳定在五秒以下，且在部署的第一周“消失的电话号码”事件完全停息。
为什么 WHERE EXCLUDED.column != table.column 在两者都是 NULL 时跳过行，且这与 PostgreSQL 的更新机制如何交互？
许多候选人假设如果两个 NULL 不相等，则比较应返回 TRUE 并允许更新。然而，SQL 使用三值逻辑：NULL 代表一个未知值。任何与 NULL 的比较（包括 NULL = NULL 或 NULL != NULL）结果都是 NULL（未知），而不是布尔 TRUE 或 FALSE。在 PostgreSQL 的 WHERE 子句中，只有评估为 TRUE 的行才会继续；NULL 被视为 FALSE。因此，当比较两个 NULL 的电话号码时，结果是 NULL，更新被跳过，系统错误地假设无需变化。IS DISTINCT FROM 对于 NULL 与 NULL 返回 FALSE，正确指示它们是相同的，仅在适当时跳过更新，而当一个值是 NULL 而另一个不是时返回 TRUE。
多列唯一约束中的列顺序如何影响 ON CONFLICT 解决的性能，且当冲突目标与索引定义未完全匹配时会发生什么？
候选人经常忽视 PostgreSQL 要求冲突目标（列在 ON CONFLICT (...) 中列出的）必须与唯一索引定义精确匹配，包括列顺序和任何功能表达式。如果存在唯一索引在 (clinic_id, external_id) 上，但查询指定为 ON CONFLICT (external_id, clinic_id)，则规划器可能无法推断索引，抛出“没有与 ON CONFLICT 规范匹配的唯一或排除约束”错误。即使成功，列顺序不匹配也会阻止优化器使用索引仅扫描来查找冲突元组，强制进行堆获取并显著增加 I/O 成本。
在 SET 子句中使用 COALESCE(EXCLUDED.column, table.column) 与使用 WHERE EXCLUDED.column IS DISTINCT FROM table.column 的区别是什么，特别是在触发执行和行版本控制方面？
在 SET 子句中使用 COALESCE 无条件地写入一个值到行（无论是新数据还是保留的旧数据）。此操作生成一个新的行版本 (CTID)，写入 WAL，并触发与表相关联的所有 BEFORE 和 AFTER 触发器，即使最终值保持与先前状态相同。这在审计表中产生“噪声”，并增加了复制负担。相反，带有 IS DISTINCT FROM 的 WHERE 子句在没有实际变化发生时完全防止行修改。不创建新的元组版本，不触发触发器，并避免 WAL 生成。这一区别对于具有审计日志或外键级联的高吞吐系统至关重要，在这些系统中，“无操作”更新会产生显著的开销。