我有一个脚本需要临时提取数据以对其进行额外操作，但在脚本运行后不需要进一步存储它。我目前在一系列临时本地表 (CREATE TABLE #table) 中有相关数据，然后在使用完成时将其删除。我正在考虑切换到以相同方式处理的物理表（CREATE TABLE 表），如果它的脚本速度会有所提高（或其他优势，也许？）。
...那么，临时表和物理表在性能上是否存在差异？根据我的阅读，临时表只是物理表，只有运行脚本的会话才能查看（减少锁定问题）。
编辑：我应该指出，我说的是物理表与临时表。有很多关于临时表与表变量的信息，例如http://sqlnerd.blogspot.com/2005/09/temp-tables-vs-table-variables.html.
【问题讨论】：
标签： sql sql-server sql-server-2005 tsql
临时表在 SQL Server 中是个大问题。
您的其他方法：创建然后删除常规表只会产生相同的开销。
另一种方法：使用现有表，用附加列扩充行，以区分可以使用哪些行与每个用户/会话相关。消除了创建/删除表的负担，但是，您将需要对生成值以区分行的代码保持偏执，并且您必须开发一种方法来维护表以应对会话过早结束的情况并且有剩余（在处理结束时未删除的行）。
我建议您重新考虑您的处理策略。一些替代方法与使用相关查询、派生表或表变量一样简单。看一看：http://www.sql-server-performance.com/articles/per/temp_tables_vs_variables_p1.aspx
编辑：创建和删除常规表的方法和重用带有附加字段的常规表的方法：两者都会生成查询计划重新编译，因为更改的数据量会触发重新评估的表统计。同样，您最好的方法是找到处理数据的替代方法。
【讨论】：
tempdb 与常规数据库相比具有日志记录优化。表变量的存储方式与临时表完全相同，因此建议毫无意义。您链接到的那篇文章关于表变量的事务日志也是完全错误的。
你在做什么样的数据操作，你在处理多少数据？
我会坚持使用临时表 - 对于大型数据集，我一直发现它是迄今为止最好的方法，而不仅仅是在 SQL Server 中。您可以尝试一个全局临时表 (CREATE TABLE ##tablename)，它的持续时间超出了 create 语句的范围。
来自 SQL Server 联机丛书 (2005)：
如果您创建全局临时 表 ##employees，该表中的任何用户 数据库可以使用此表。如果 没有其他用户使用此表 创建后，表是 断开连接时删除。如果 另一个用户使用该表 创建后，SQL Server 断开连接后将其删除并 在所有其他会话不再 积极使用它。
【讨论】：
要考虑的一件事是您是否可以指望一次只运行一个用户运行此过程。如果您同时有用户，那么常规表选项可能会产生干扰。临时表对用户来说可能是唯一的。
【讨论】：
至少对于 MySql，您将获得的唯一时间节省是实际创建临时表的时间节省。 AFAIK 所有表格在磁盘上的处理方式都是一样的，它们只是在会话结束时消失了。这也是我在实践中看到的。同样，这是 mysql 4.x 和 5.x
【讨论】：
我对此不是 100% 确定，但我相信表变量严格存储在内存中，但临时表驻留在存储在磁盘上的 tempdb 中。这是使用 SQL Server，我不确定不同 RDMS 的一致性如何。
【讨论】：