更新语句中的冗余数据
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
实际上更像是DELETE
plus 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的发行说明:
UPDATE
s和DELETE
s留下死元组,失败的INSERT
s也是如此。以前只能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,因此页面上必须有可用空间。
以上是 更新语句中的冗余数据 的全部内容, 来源链接: utcz.com/qa/404041.html