我应该提交还是回滚创建临时表、读取然后删除它的事务？答案

【问题标题】：Should I commit or rollback a transaction that creates a temp table, reads, then deletes it?我应该提交还是回滚创建临时表、读取然后删除它的事务？
【发布时间】：2011-02-22 03:54:45
【问题描述】：

要选择与数百个 ID 列表相关的信息...而不是创建一个巨大的选择语句，我创建临时表，将 ID 插入其中，将其与表连接以选择与 ID 匹配的行，然后删除临时表。所以这本质上是一个读取操作，不会对任何持久性数据库表进行永久性更改。

我在事务中执行此操作，以确保在完成后删除临时表。我的问题是......当我提交这样一个事务与让它回滚时会发生什么？

性能方面...数据库引擎是否需要做更多的工作来回滚事务而不是提交事务？由于唯一的修改是对临时表进行的，因此甚至有区别吗？

这里有相关问题，但没有回答我涉及临时表的具体案例：Should I commit or rollback a read transaction?

编辑（澄清问题）：

在提交/回滚之前不寻求建议。交易是绝对必要的。假设没有错误发生。假设我已经创建了一个临时表，假设我知道发生了对 tempdb 的真正“工作”写入，假设我在事务中执行只读（选择）操作，并假设我在临时表上发出了删除语句。毕竟......哪个更便宜，提交或回滚，为什么？基于这种涉及临时表和其他只读操作的特定场景，数据库引擎在那个点可能针对提交与回滚做哪些其他工作？

【问题讨论】：

标签： sql-server-2008 transactions commit effects rollback

【解决方案1】：

如果我们谈论的是本地临时表（即名称以单个 # 为前缀），则在您关闭连接的那一刻，SQL Server 将终止该表。因此，假设您的数据层经过精心设计以尽可能短地保持连接打开，我不会担心将临时表的创建包装在事务中。

我认为将表包装在事务中可能会有轻微的性能差异，但我敢打赌，与由于创建和填充事务的时间而使事务保持更长时间的成本相比，它是如此之小以至于无关紧要临时表。

【讨论】：

我并没有真正询问将其包装在事务中的性能。连接依次传递给多个数据库 API 函数，它们使用通用的临时表名称/约定，因此需要保证删除临时表的事务。我感兴趣的是提交该事务或回滚它的效果。
@Triynko - 您对效果的哪些方面感到好奇？从其他代码访问临时表？
@Thomas - 我在询问提交与回滚事务的性能。这真的不直观，因为回滚似乎意味着工作将完成，但如果这样一个简单的未提交事务被回滚......该工作可能只是从内存中删除并且不会记录“应用”更改的工作，例如更新数据库统计信息。这很难说，所以我真的在寻找一个知道在这种特定场景下回滚和提交期间 SQL Server 中可能发生的事情的人。
@Triynko - 我想我理解这种困惑。即使某事在事务中，“工作”仍然完成。即使您在事务中创建临时表，填充它，做一堆工作然后回滚，将表放入 tempdb 并将数据写入磁盘的工作，就好像它不在事务中一样，仍然完成。唯一的区别是，这项工作对于使用普通事务隔离级别的事务之外的代码是不可见的。
@Triynko - 请记住，如果您的整个操作不在事务中，则每个 DDL 或 DML 语句本身就是一个事务。所以，现在的问题是大提交/回滚是否比许多较小的提交/回滚便宜。从长远来看，IMO 并不便宜，因为长时间运行的事务可能会造成额外的阻塞。

【解决方案2】：

确保临时表被删除的更简单方法是使用# 符号创建它。

创建表#mytable ( 行 ID 整数，行名 char(30) )

# 告诉 SQL Server 该表是本地临时表。此表仅对 SQL Server 的此会话可见。当会话关闭时，该表将被自动删除。您可以像对待任何其他表一样处理此表，但有一些例外。唯一真正的主要问题是您不能在临时表上设置外键约束。其他的都在 Books Online 中介绍。

临时表在 tempdb 中创建。

如果您这样做，则不必将其包装在事务中。

【讨论】：

我说我已经在使用#temp 表了。但是连接被重用，因为它被快速连续地传递给多个数据库 API 函数，所以重要的是有一个事务，它在完成时显式删除表，或者通过执行删除和提交，或者通过回滚事务。我对提交或回滚事务的影响特别感兴趣（假设表在提交之前肯定被删除，并且可能在回滚之前被删除）。