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

Posted 2021-04-20

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

任何见解将不胜感激。我只是担心我没有遵循我创建的临时表的最佳实践。

谢谢，

小号

答案

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

另一答案

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

另一答案

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

另一答案

我曾经陷入让后台服务器进程清理对象的人群中，但是，最近出现极端TempDB日志文件增长的问题已经改变了我的观点。我不确定每个版本的SQL Server是否一直如此，但是自从转向SQL 2016并将驱动器放在PureStorage SSD阵列上之后，情况就会有所不同。进程通常是CPU绑定而不是I / O绑定，并且显式删除临时对象不会导致日志增长问题。虽然我没有深入挖掘为什么，但我怀疑它与.NET世界中的垃圾收集不同，它在显式调用时是同步的，而在离开系统时是异步的。这很重要，因为显式丢弃会释放日志文件中的存储，并使其在下一次日志备份时可用，而在未明确删除对象时似乎不是这种情况。在大多数系统上，这可能不是一个大问题，但在支持大量ERP和Web店面以及许多并发事务的系统上，以及大量使用TempDB时，它产生了很大的影响。至于为什么要首先创建TempDB对象，大多数查询中的数据量，无论如何都会溢出到TempDB存储中，因此创建具有必要索引的对象通常更有效，而不是让系统自动处理它。

另一答案

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