单个语句的交易是做什么的?

我了解一个事务如何协调一对更新。 我不明白的是在交易中包装单一的陈述,这是我所见过的90%。 实际上,在现实生活中,根据我的经验,find一系列逻辑上相关的交易,每个交易都包含在自己的交易中,但是整个交易并没有包含在交易中。

在MS-SQL中,在事务中包装单选,单更新,单插入或单删除有什么好处?

我怀疑这是迷信的编程。

它什么都不做。 所有单独的SQL语句(极less数情况下,例如大容量插入无日志或截断表)都是自动的“在事务中”,无论您是否明确地说出来(即使它们插入,更新或删除数百万行) 。

编辑:基于@ Phillip的评论下面…在当前版本的SQL Server中,即使大容量插入和截断表也写入一些数据到事务日志,虽然没有其他操作那么多。 从事务angular度来看,关键的区别在于,在这些其他types的操作中,被修改的数据库表中的数据不会处于允许回退状态的日志中。

所有这一切意味着语句对数据库中的数据进行的更改将logging到事务日志中,以便在操作失败时可以撤​​消它们。

“Begin Transaction”,“Commit Transaction”和“Rollback Transaction”命令提供的唯一function是允许您将两个或多个单独的SQL语句放入同一个事务中。

编辑:(加强标记评论…)是的,这可能是由于“迷信”编程,也可能是数据库交易性质的根本误解。 更为慈善的解释是,这只是过度应用一致性的结果,这是不恰当的,而爱默生委婉语的另一个例子是:

愚蠢的一致性是小心灵的大地精,
受到小政治家,哲学家和神学家的喜爱

正如查尔斯·布雷塔那(Charles Bretana)所说,“它什么都不做” – 除了已经完成的事情之外,什么也没有。

有没有听说过关系数据库的“ACID”要求? “A”代表Atomic,意味着声明可以全部工作,也可以不工作,并且在执行声明的同时, 不会 对受该查询影响的数据进行其他查询。 BEGIN TRANSACTION / COMMIT将这个lockingfunction“扩展”到多个语句所做的工作中,但是它并没有增加单个语句。

但是,数据库事务日志总是写入到数据库被修改(插入,更新,删除)的时候。 这不是一个select,这是一个往往会激怒人的事实。 是的,有批量插入和恢复模式,但它仍然被写入的Wierdness。

我也会在这里说出隔离级别。 这样做会影响个别命令,但是这样做仍然不会使“声明事务包装”查询的执行与“独立”查询有所不同。 (请注意,对于多语句声明的事务,它们可能非常强大而且非常危险。)另请注意,“nolock”不适用于插入/更新/删除 – 这些操作始终需要locking。

对于我来说,在一个事务中包装单个语句意味着如果我在执行一次手动的UPDATE语句时忘记了一个WHERE子句,我就有能力回滚它。 它救了我几次。

例如

 -------------------------------------------------------------- CREATE TABLE T1(CPK INT IDENTITY(1,1) NOT NULL, Col1 int, Col2 char(3)); INSERT INTO T1 VALUES (101, 'abc'); INSERT INTO T1 VALUES (101, 'abc'); INSERT INTO T1 VALUES (101, 'abc'); INSERT INTO T1 VALUES (101, 'abc'); INSERT INTO T1 VALUES (101, 'abc'); INSERT INTO T1 VALUES (101, 'abc'); INSERT INTO T1 VALUES (101, 'abc'); SELECT * FROM T1 -------------------------------------------------------------- /* MISTAKE SCENARIO (run each row individually) */ -------------------------------------------------------------- BEGIN TRAN YOUR_TRANS_NAME_1; /* open a trans named YOUR_TRANS_NAME_1 */ UPDATE T1 SET COL2 = NULL; /* run some update statement */ SELECT * FROM T1; /* OOPS ... forgot the where clause */ ROLLBACK TRAN YOUR_TRANS_NAME_1; /* since it did bad things, roll it back */ SELECT * FROM T1; /* tans rolled back, data restored. */ -------------------------------------------------------------- /* NO MISTAKES SCENARIO (run each row individually) */ -------------------------------------------------------------- BEGIN TRAN YOUR_TRANS_NAME_2; UPDATE T1 SET COL2 = 'CBA' WHERE CPK = 4; /* run some update statement */ SELECT * FROM T1; /* did it correctly this time */ COMMIT TRAN YOUR_TRANS_NAME_2 /* commit (close) the trans */ -------------------------------------------------------------- DROP TABLE T1 -------------------------------------------------------------- 

一个可能的借口是,这个单一的语句可能会导致一堆其他的SQL通过触发器运行,并且他们正在防止在那里坏事,虽然我希望任何DBMS有常识使用隐式事务同样的方式已经。

我能想到的另一件事是,有些API允许你禁用自动提交,而代码的编写只是为了防止有人这样做。

当您启动显式事务并发出DML ,由语句locking的资源将保持locking状态,并且直到您手动提交或回滚事件才会从事务外部看到语句的结果。

这是你可能或不需要的。

例如,您可能想要向外界显示初步结果,同时仍然locking它们。

在这种情况下,您启动另一个事务,在第一个事务提交之前发出locking请求,从而避免竞争状况

隐式事务在DML语句完成或失败后立即被提交或回滚。