仓库中使用的物理表是临时表。有什么优势吗？

Question

正如我在之前的帖子中所说，我继承了一个基于 SQL Server 框架的仓库。

在我对现有组件和前辈采用的做法的持续审查中，我发现了一些引起我注意并令我惊讶的事情：有几个地方正在使用物理表作为临时表来操作大量数据。第一反应是认为这种做法对 DBMS 来说非常昂贵，但希望对此有更多反馈。

关于这个主题的一些注释：

• 在 SP 中创建/删除物理表（称为“TMP_TableName”的表）
• 主要用于处理大量数据的表格
• 在日常夜间处理过程中多次提到 SP 调用

问题：

1. 这种做法是否会为我不知道的处理例程带来任何优势？
2. 是否有这方面的最佳实践？
3. 我的计划是更新代码以使用#temp 表来提高性能。对此有何评论？
4. 我应该考虑使用变量表吗？我读到使用大数据处理时性能很差。

感谢任何基于您的知识/经验的反馈，您可能希望与所有 stackoverflowers 分享。

提前致谢，

Answer 1

临时表 (#temp) 是用户表，就像您在数据库中创建的任何其他表一样，但有一个重要区别。实例化时，它们在 tempdb 中被赋予一个唯一的名称。这样，如果多个连接调用相同的过程，它们就不会相互踩踏临时表。

临时表的最佳做法通常是使用#temp。想到的一个快速例外是您知道一次只能由一个进程使用的永久临时表。

我要么改用#temp 表，要么将它们创建为永久临时表。

我一般不使用表变量。它们仍然是临时表并存储在 tempdb 中，但是一旦创建它们就可以被索引和操作的方式非常有限。话虽如此，它们对于少量相当静态的数据很有用。有一些操作只能使用一个与另一个。

有关临时表和表变量之间差异的更多信息，请参阅here，有关详细说明，请参阅here

希望有帮助！

粘土

Answer 2

1. 这种做法是否会为我不知道的处理例程带来任何优势？

您可以通过将特定数据转储到表中并创建特定索引等来提高性能。即，如果多次使用相同的大型但有限的数据集，或者如果您有一个需要计算的列指数。无论如何，这通常发生在 SQL 的幕后，无论是通过缓存/假脱机等。

1. 是否有这方面的最佳做法？

就我个人而言，我会保持表格完好无损，以便之后进行调试。如果您要这样做，您将需要在每次运行时预先清除表格的代码

当前方法有一个严重的缺点：如果两个进程同时运行存储过程，数据将“冲突”

我的计划是更新代码以使用 #temp 表来改进 表现。对此有何评论？

除非您的数据库位于慢速磁盘上而您的 tempdb 位于快速磁盘上，并且您的 RAM 不足，因此它必须一直使用该磁盘，否则性能不太可能发生任何变化。

这将解决了 SP 与多个进程同时运行的问题。

我应该考虑使用变量表吗？ 我读到使用大数据处理时性能很差

基本上没有......在之前的帖子中完全介绍过。

总之转换为临时 (#) 表，除非您需要调试进程