【问题标题】:Fast update query on millions table百万表的快速更新查询
【发布时间】:2015-09-09 14:18:35
【问题描述】:

我正在使用一个简单的查询来更新一个包含数百万条记录的表,但它需要大量的时间,想知道是否有人可以带来一些魔术来加快下面的过程查询

UPDATE sources.product
   SET partial=left(full,7);

【问题讨论】:

  • 试图以更小的块进行?太大的交易可能会减慢速度。
  • 你知道这个查询会更新你表中的每条条记录,对吧?
  • 问题是你为什么要这样做?您需要将完整列的数据复制到部分吗?视图不能这样做吗? (数据不一致安全替代方案。)
  • 我在这里和 jarlh 在一起。如果您希望partial 始终等于left(full,7),则不要存储它。你只会引入冗余。另一方面,如果partial 会发生变化,那么这只是一次仅完成一次的初始填充,那么为什么要关心它所花费的时间呢?
  • 不,它通常没有那么快,因为必须进行字符串操作,而不仅仅是读取值。但是您可以创建一个功能索引以便快速访问:create index idx_product_leftfull7 on product( left(full,7) );。因此,您可以快速获得它,而且您的数据没有任何冗余。

标签: sql postgresql sql-update pgadmin sql-optimization


【解决方案1】:

您需要缩小行数以使其运行得更快。尝试一些事情:

  1. 减少partial 列的索引数。当您更改 partial 时,每个索引都需要更新,因此一次更新可能会导致 2 或 3 次其​​他更新。

  2. 为您的行添加时间戳,以便您只更新新行。

  3. 创建一个触发器以在插入或更新行时更新partial

【讨论】:

  • 表是稳定的,不会出现新的添加,只需要在现有的(full)的基础上添加这个额外的属性(partial),此时属性partial也没有索引跨度>
  • 如果这是一项一次性工作,那就顺其自然吧。
【解决方案2】:

如果一个表包含大数据,索引是必要的,我认为你应该尝试重新索引,然后尝试使用这个命令。

【讨论】:

  • 索引通常会使更新变慢......因为它必须同时更新基础表和索引。索引加速查询,而不是更新,除非它是对更新的引用的索引。
猜你喜欢
  • 1970-01-01
  • 2018-01-01
  • 1970-01-01
  • 2020-03-07
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-08-15
  • 1970-01-01
相关资源
最近更新 更多