更新大量数据postgresql

我有两个主要的表格：账户和项目。一个帐户可以有多个项目。也就是说，我的项目表有超过400万条记录

问题是，我有一个拥有超过41k个项目的帐户，我想将其项目的deleted_at列更新为实际的时间戳，但我的查询没有完成。我收到一个错误，表示由于超时而无法完成查询

这是我正在尝试运行的查询：

更新已删除的项目集，时间为：2015-12-23 19:10:00，其中账户id=859

即使在较小的帐户中，由于数据库中存储了大量项目，查询也需要很长时间才能完成

但是，如果我选择了帐户的所有项目，查询将在近3秒钟内完成，我认为这是可以接受的。所以，我想问题可能与更新本身有关

那么，我能做些什么来更新这些记录呢

我现在面临的另一个问题是，此时项表的增长，如果我从项运行selectcount*，我也会得到一个超时

我需要知道我能做些什么，如何优化数据库以达到这一目的，以及如何应对记录数量的增加

谢谢

编辑1：

我在更新运行SELECT relation:：regclass时检查pg_锁，如果未授予，则检查pg_锁；什么也没显示出来。因此，我假设查询没有等待任何锁

我试图运行解释分析，缓冲区选择*从。。。项目表和科目表都有。我的live数据库中的项查询从未完成，但再次超时…，因此我在本地转储中运行了它。这些是我得到的结果

Account - Remote database
---------------------------
"QUERY PLAN"
"Seq Scan on \"Account\"  (cost=0.00..532.45 rows=4245 width=539) (actual time=0.032..8.919 rows=4247 loops=1)"
"  Buffers: shared hit=97 read=393 written=31"
"Planning time: 0.063 ms"
"Execution time: 12.849 ms"

Item - Local dump
---------------------------
"QUERY PLAN"
"Seq Scan on \"Item\"  (cost=0.00..869926.62 rows=19644062 width=233 (actual time=8.408..11660.646 rows=19492549 loops=1)"
"  Buffers: shared hit=4171 read=669315"
"Planning time: 0.323 ms"
"Execution time: 14055.453 ms"

正如您所要求的，这是我的表格结构：

帐户id、帐户名称、uID、云id、创建时间、更新时间、用户id、删除时间

帐户索引：无

帐户约束：id->主键，用户id->外键，云id->外键

项目id、名称、是否收藏夹、上次修改、项目id、父项目id、项目大小、项目类型、只读、mime类型、创建时间、更新时间、删除时间、云项目id、帐户id

项目约束：id->主键，帐户id->外键，项目id->唯一

项目索引：帐户id、云项目id、创建地点、项目名称、父项目id、项目id

我之所以创建这个索引，是因为这些字段是我主要用来搜索项目的字段。我不知道这是否也是问题的一部分

所有表的所有外键的onUpdate设置为CASCADE，onDelete设置为set NULL

此外，这两个表中没有删除任何内容。如果您删除一个帐户或项目，我们会将时间戳处已删除的_设置为实际的

表大小或记录数： 账户：4.247，项目：19.492.549是的，比我最初告诉你的多得多

另一个有趣的事实是，如果我将运行在Azure Virtual机器上的live数据库导入到我的机器中，尽管查询需要很长时间，但它会完成。另一方面，在远程数据库中，我甚至无法计算存储的项目总数。我的本地机器有一个SSD，虚拟机没有

VM规格：2核、7 GB RAM、1个最大IOPS为500的数据磁盘

我用的是Postgres9.4

如果您需要更多信息，请告诉我，我很乐意提供给您

---

谢谢大家!

这听起来好像是在等待锁定，而不是等待语句真正花费这么长时间。检查pg_locks以查看您的更新是否正在等待：就慢速选择而言，请阅读以下内容：并提供缺少的信息编辑您的问题。虽然不相关，但是：你真的应该避免那些可怕的引用标识符，它们比它们值得的麻烦多了。那些你引用的关于声音的4 mil/41k的卷远不是压倒性的。。。你能展示你的表的结构，特别是约束和索引吗？谢谢你们的帮助！我已经用你要求的额外信息更新了帖子@a_horse_，没有_name@Hambone我已经用约束、索引和其他一些附加信息更新了这篇文章。谢谢