更新语句中的冗余数据

Hibernate会生成UPDATE包含所有列的语句,无论我是否更改了这些列中的值,例如:

tx.begin();

Item i = em.find(Item.class, 12345);

i.setA("a-value");

tx.commit();

发表以下UPDATE声明:

update Item set A = $1, B = $2, C = $3, D = $4 where id = $5

因此B,C,D列已更新,而我没有更改它们。

tx.begin();

em.createQuery("update Item i set i.a = :a where i.id = :id")

.setParameter("a", "a-value")

.setParameter("id", 12345)

.executeUpdate();

tx.commit();

最让我困惑的是,EXPLAIN“未优化”和“优化”查询版本的计划是相同的!

回答:

由于PostgreSQL MVCC,an

UPDATE实际上更像是DELETEplus INSERT。除了烘烤值的显着例外-请参阅:

  • Postgres是否在更新时重写整行?

(和仅堆元组的微小差异- DELETE+ INSERT启动了一个新的HOT链-但这与手头的情况无关。)

准确地说,“删除”行对于提交删除之后开始的任何事务来说都是不可见的,以后再进行清理。因此,在数据库方面,包括索引操作,实际上这两个语句之间

。(有例外,请继续阅读。)这会稍微增加网络流量(取决于您的数据),并且需要一些解析。

在@araqnid输入之后,我研究了HOT更新,并进行了一些测试。就HOT更新而言, 列更新

。我的答案成立。请参阅下面的详细信息。

这也适用于烘烤的属性,因为除非值 否则它们也不会被触摸。

,如果您使用 (第9.0页介绍),则可能会有不希望的副作用!

我引用了有关触发器的手册:

…这样的命令UPDATE ... SET x = x ...将在列上触发触发器x, 。

大胆强调我的。

抽象层是为了方便。它们对于不懂SQL的开发人员或在不同RDBMS之间需要可移植的应用程序很有用。不利的一面是,它们可能会削弱性能并引入其他故障点。我会尽可能避免它们。

HOT(仅堆元组)更新

Postgres

8.3引入了仅堆元组,在8.3.4和8.4.9中进行了重要改进。

Postgres 8.3的发行说明:

UPDATEs和DELETEs留下死元组,失败的INSERTs也是如此。以前只能VACUUM回收死元组占用的空间。使用HOT死元组空间可以在INSERTUPDATE

时自动回收 。这样可以实现更一致的性能。同样,HOT避免添加重复的索引条目。

强调我的。并且“无更改”包括使用相同的值更新列的情况。我不确定, 。

最终,源代码中广泛的README.HOT确认了这一点。

烤列也不会妨碍HOT更新。HOT更新的元组仅链接到关系的吐司中的相同,未更改的元组。HOT更新甚至可以与目标列表中的烘烤值(实际上是否更改)一起工作。如果更改了烘烤值,则显然需要对烘烤关系叉进行写操作。我也测试了所有这些。

不要相信我,自己去看看。Postgres提供了一些检查统计信息的功能。在UPDATE有和没有所有列的情况下运行您的应用程序,并检查是否有任何不同。

-- Number of rows HOT-updated in table:

SELECT pg_stat_get_tuples_hot_updated('table_name'::regclass::oid)

-- Number of rows HOT-updated in table, in the current transaction:

SELECT pg_stat_get_xact_tuples_hot_updated('table_name'::regclass::oid)

或使用pgAdmin。选择表并检查主窗口中的“统计”选项卡。

请注意,只有在主关系分支的同一页上有新元组版本的空间时,才可以进行HOT更新。强制该条件的一种简单方法是使用仅容纳几行的小表进行测试。页面大小通常为8k,因此页面上必须有可用空间。

以上是 更新语句中的冗余数据 的全部内容, 来源链接: utcz.com/qa/404041.html

回到顶部