我疯了:PostgreSQL IN运算符使用嵌套查询返回意外结果

我疯了:PostgreSQL IN运算符使用嵌套查询返回意外结果,第1张

概述以下查询返回2036行: SELECT "FooUID" from "Foo" fLEFT 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'WHER 以下查询返回2036行:
SELECT "FooUID" from "Foo" fleft 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" f1WHERE 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" ffSET "barUID" = 'aNewUID'WHERE ff."barUID" IS NOT NulLAND NOT EXISTS (   SELECT * FROM "bar" bb   WHERE bb."barUID"= ff."barUID")

但是,我仍然不明白为什么原来没有接他们.如果嵌套查询选择了166“FooUID”,为什么它们不会与使用IN的“Foo”表中的行匹配?

编辑4:我想的越多,这个背景可能很重要:

这一切都发生在最近从另一个克隆的数据库服务器上.我跟那个做克隆的IT人员交谈过,结果发现他没有关闭在原始数据库之上运行的应用程序,然后将其删除以克隆它.这意味着数据库很可能在交易中被放下(我不知道如何不合理).是否有可能数据库中的某些东西处于损坏的状态,导致我看到这些幻像行?

不幸的是,我无法再重复它,因为运行wildplasser的修复程序.原始数据库(再次启动并提供应用程序)没有我试图在副本上修复的无效数据,更不用说我目睹的任何诡计.

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

如果你用NOT EXIST重写它会发生什么,比如
UPDATE Foo ffSET baruID = 'aNewUID'WHERE ff.baruID IS NOT NulLAND NOT EXISTS (SELECT * FROM bar bb    WHERE bb.baruID = ff.baruID    );

看起来比选择外连接的肢体腿更清洁.

总结

以上是内存溢出为你收集整理的我疯了:PostgreSQL IN运算符使用嵌套查询返回意外结果全部内容,希望文章能够帮你解决我疯了:PostgreSQL IN运算符使用嵌套查询返回意外结果所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/1181791.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-06-02
下一篇 2022-06-02

发表评论

登录后才能评论

评论列表(0条)

保存