显式删除临时表或让SQL Server处理它

Question

处理临时表删除的最佳做法是什么。我已经读过你应该显式处理drop以及sql server应该处理drop ....正确的方法是什么？我总是觉得你应该自己清理你在sproc中创建的临时表等等。但是，然后我发现了其他一些不同的东西。

非常感谢任何见解。我只是担心我没有遵循我创建的临时表的最佳实践。

谢谢，

取值

Answer 1

我的观点是，首先看看你是否真的需要临时表 - 或者 - 你可以用CTE做。其次，我总是放弃临时表。有时你需要有一个作为连接的临时表（例如## temp），所以如果你第二次运行查询，并且你有明确的代码来创建临时表，你会得到一个错误，表明该表已经存在。自己清理后总是一个很好的软件实践。

Answer 2

本地临时表（名称中的单个＃）将在超出范围时自动删除，因此如果范围是短暂的（例如存储过程），则显式删除是没有意义的。

Answer 3

在一个多线程场景中，每个线程创建自己的一组表并且线程数被限制，而不是删除自己的表意味着调控器会考虑你的线程完成并产生更多线程...但是temp表仍然存在（因此与服务器的连接）因此您将超出您的州长的限制。如果你手动删除临时表，那么线程在它们被删除并且没有产生新线程之前就不会完成，从而保持了调控器不会压倒SQL引擎的能力

Answer 4

我曾经陷入过让对象被后台服务器进程清理的人群，但是，最近TempDB日志文件的极端增长问题改变了我的看法。我不确定每个版本的SQL Server是否都是这种情况，但是由于迁移到SQL 2016并将驱动器放在PureStorage SSD阵列上，因此运行情况有所不同。进程通常是受CPU约束，而不是受I / O约束，并且显式删除临时对象不会导致日志增长。尽管我还没有深入探讨为什么，但是我怀疑它与.NET世界中的垃圾回收没有什么不同，在.NET世界中，垃圾回收在显式调用时是同步的，在留给系统时是异步的。这很重要，因为显式删除将释放日志文件中的存储，并使其在下一次日志备份中可用，而当未显式删除对象时，情况似乎并非如此。在大多数系统上，这可能不是什么大问题，但是在支持具有大量并发事务且大量使用TempDB的高容量ERP和Web店面的系统上，它产生了很大的影响。至于为什么首先要创建TempDB对象（大多数查询中都有大量数据），无论如何它都会溢出到TempDB存储中，因此通常创建具有必要索引的对象要比让对象更有效。系统会自动处理它。

Answer 5

根据我的观点。无需显式删除临时表。 SQL服务器将处理以删除临时数据库中存储的临时表，以便在处理空间时处理查询。