由于可能引起的问题,这种发生的可能性似乎极不可能,但我认为我还是问这个问题...

想象一下交易,其中涉及自动插入ID并分配值。提交之前,涉及的代码缓存了分配的ID的副本,以供以后参考。然后进行交易。

假设没有直接的客户干预(记录的删除或更改),是否有任何数据库或情况会在提交时立即自动更改ID值,从而使缓存ID不正确?缓存ID中期时总是安全吗?

我可以想象的一个假设情况是,如果某些RDBMS实施莫名其妙地认为有必要具有无间隙和时间依赖时间的自动启动值(因为我看到许多人想要这个的例子)。在这种假设的情况下,我可以想象可能会做一些神奇的ID改组,以填补另一笔交易中ID分配后回滚引起的空白(或其他GAP CAUSER)。这将使缓存值无效。

有人知道这种实现还是其他缓存杀手?

有帮助吗?

解决方案

生成的ID值的实现通常涉及在短原子操作中递增反值。然后,请求交易将其用于此值,即使该交易会向后回滚,保留值也永远不会回到自由值池。因此,我认为所描述的情况不太可能。另外,在PL/SQL类型的程序类型中,您确实需要生成的值是正确的,以便将其他相关行插入子表中。

至于想要时间订购的无间隙ID值的人:自动启动/替代键的唯一目的是为行创建人工标识。它应该与确定创建行的顺序无关。有更好的方法可以做到这一点,例如使用创建时间戳。

其他提示

PostgreSQL 支持 DEFERRED 可以更改数据的触发器 COMMIT.

CREATE TABLE test_autoinc (id BIGSERIAL);

CREATE TABLE test_other (id BIGSERIAL);

CREATE FUNCTION prc_update_autoinc()
RETURNS TRIGGER
AS
$$
BEGIN
        UPDATE  test_autoinc
        SET     id = id + 10;
        RETURN  NEW;
END;
$$
LANGUAGE 'plpgsql';

CREATE CONSTRAINT TRIGGER
        trg_other_ai
AFTER INSERT
ON      test_other
DEFERRABLE
INITIALLY DEFERRED
FOR EACH ROW
EXECUTE PROCEDURE prc_update_autoinc();

BEGIN TRANSACTION;

INSERT
INTO    test_autoinc
DEFAULT VALUES;

INSERT
INTO    test_other
DEFAULT VALUES;

SELECT  *
FROM    test_autoinc;

COMMIT;

SELECT  *
FROM    test_autoinc;

首先 SELECT (就在 COMMIT)返回 1, ,第二个(紧随其后 COMMIT)返回 11.

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top