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