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运算符使用嵌套查询返回意外结果所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)