我疯了吗：带有嵌套查询的 PostgreSQL IN 运算符返回意外结果

Question

以下查询返回 2036 行：

SELECT "FooUID" from "Foo" f
LEFT JOIN "Bar" b ON f."BarUID" = b."BarUID"
WHERE f."BarUID" IS NOT NULL AND b."BarUID" IS NULL

但以下语句仅更新了 1870 行：

UPDATE "Foo" f1 set "BarUID" = 'aNewUID'
WHERE f1."FooUID" IN (
   SELECT f2."FooUID" from "Foo" f2
   LEFT JOIN "Bar" b ON f2."BarUID" = b."BarUID"
   WHERE f2."BarUID" IS NOT NULL AND b."BarUID" IS NULL
)

这怎么可能？

编辑1：第一个查询继续返回166行，第二个查询继续更新0行。

编辑2：

在下面，嵌套查询返回包含UID的行，但外部查询返回0行。

SELECT * from "Foo" f1
WHERE f1."FooUID" = (
   SELECT f2."FooUID" FROM "Foo" f2
   LEFT JOIN "Bar" b ON f2."BarUID" = b."BarUID"
   WHERE f2."BarUID" IS NOT NULL AND b."BarUID" IS NULL
   LIMIT 1
)

我疯了吗？

编辑3：

由@wildplasser提供的以下语句成功更新了剩余的166行：

UPDATE "Foo" ff
SET "BarUID" = 'aNewUID'
WHERE ff."BarUID" IS NOT NULL
AND NOT EXISTS (
   SELECT * FROM "Bar" bb
   WHERE bb."BarUID"= ff."BarUID"
)

不过，我还是不明白为什么原著没有收录它们。如果嵌套查询选择了 166 个 "FooUID"，为什么它们不能与使用 IN 的 "Foo" 表中的行匹配？

编辑4：我想得越多，这个背景可能就越重要：

这一切都发生在最近从另一台克隆的数据库服务器上。我与进行克隆的 IT 人员进行了交谈，结果发现他在将原始数据库进行克隆之前没有关闭在原始数据库上运行的应用程序。这意味着数据库很可能在交易过程中被关闭（我不知道有多不礼貌）。数据库中的某些内容是否有可能处于损坏状态，导致我看到这些幻象行？

不幸的是，自从运行了 wildplasser 的修复程序后，我无法再重现它。原始数据库（再次启动并为应用程序提供服务）没有我试图在副本上修复的无效数据，更不用说我目睹的恶作剧的任何痕迹了。

我应该提到的是，在运行修复之前，我将问题简化为最基本的荒谬：我首先从编辑 2 中的嵌套查询中选择了 FooUID，将其复制到剪贴板，然后运行一个查询，选择来自 Foo，其中 FooUID 等于粘贴的值 - 这仍然返回 0 行。

Answer 1

如果你用 NOT EXIST 重写这个，会发生什么，就像

UPDATE Foo ff
SET baruid = 'aNewUID'
WHERE ff.baruid IS NOT NULL
AND NOT EXISTS (SELECT * FROM bar bb
    WHERE bb.baruid = ff.baruid
    );

在我看来比选择外部连接的肢体腿干净得多。