更新语句中的冗余数据

一尘不染

更新语句中的冗余数据

hibernate

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列已更新，而我没有更改它们。

说，项目会经常更新，并且所有列都已建立索引。问题是：将Hibernate部分优化为如下所示是否有意义：

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“未优化”和“优化”查询版本的计划是相同的！

阅读 381

2020-06-20

共1个答案

一尘不染

由于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死元组空间可以在INSERT或UPDATE
在未更改索引列 时自动回收。这样可以实现更一致的性能。同样，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，因此页面上必须有可用空间。

2020-06-20