正如我在之前的文章中所说，我继承了一个基于 SQL Server 框架的仓库。
在对现有组件和前人采用的做法的不断审查中，我发现了一些引起我注意并让我惊讶的事情：有几个地方正在使用物理表作为临时表来操作大量数据。第一反应是认为这种做法对 DBMS 来说非常昂贵，但希望对此有更多反馈。
关于这个主题的一些注释：
问题：
我很感激任何基于您的知识/经验的反馈，您可能想与所有stackoverflowers分享。
提前致谢，
临时表 (#temp) 是用户表，就像您在数据库中创建的任何其他表一样，但有一个重要区别。实例化时，它们在 tempdb 中被赋予一个唯一的名称。这样，如果多个连接调用相同的过程，它们就不会互相踩踏临时表。
临时表的最佳实践通常是使用#temp。想到的一个快速例外是永久临时表，您知道它一次只能由一个进程使用。
我要么切换到#temp 表，要么将它们创建为永久临时表。
我一般不使用表变量。它们仍然是临时表并存储在 tempdb 中，但是一旦创建它们就可以被索引和操作的方式非常有限。话虽如此，它们对于少量相当静态的数据很有用。有一些操作只能使用一个与另一个。
有关临时表和表变量之间差异的更多信息，请参见此处，详细说明请参见此处
希望有帮助！
粘土
- 这种做法是否为我不知道的处理程序带来了任何好处？
您可以通过将特定数据转储到表中并创建特定索引等来提高性能。即，如果多次使用相同的大但有限的数据集，或者如果您有一个需要索引的计算列。无论如何，这通常发生在 SQL 的幕后，无论是通过缓存/假脱机等。
- 有没有这方面的最佳实践？
就我个人而言，我会保持桌子完好无损，以便之后进行调试。如果您要这样做，则需要在每次运行时预先清除表格的代码
当前方法有一个严重的缺点：如果两个进程同时运行存储过程，数据将“冲突”
我的计划是更新代码以使用#temp 表来提高性能。对此有何评论？
除非您的数据库在慢速磁盘上，而您的 tempdb 在快速磁盘上，并且您的 RAM 不足，因此它必须一直使用磁盘，否则性能不太可能发生任何变化。
不过，这将解决 SP 与多个进程同时运行的问题。
我应该考虑使用变量表吗？我读到使用大数据处理时性能很差
基本上没有......在之前的帖子中完全介绍过。
总之，除非您需要调试进程，否则转换为临时 (#) 表