SQL中临时表与物理表的比较速度是多少？

我有一个脚本，它需要临时提取数据以对其执行额外的操作，但在脚本运行后不需要进一步存储数据。目前，我在一系列临时本地表（createtable#TABLE）中拥有有问题的数据，这些表在使用完成后会被删除。我正在考虑切换到物理表，以同样的方式处理（创建表），如果它的脚本速度有改进的话（或者其他优势，也许？）

…那么，临时表和物理表之间的性能是否存在差异？据我所知，临时表只是物理表，只有运行脚本的会话才能查看（减少锁定问题）

---

编辑：我应该指出，我谈论的是物理表和临时表。关于临时表和表变量，有很多可用的信息，例如..

对于MySql，您将得到的唯一节省时间是实际创建临时表所节省的时间。如果磁盘上的所有表都被视为相同的，那么它们只是在会话结束时碰巧消失了。这也是我在实践中看到的。同样，这是mysql 4.x和5.x，对此我不是100%确定，但我相信表变量严格地在内存中，而临时表则驻留在存储在磁盘上的tempdb中。这是在使用SQL Server，我不确定不同的RDM在这方面有多一致。

临时表在SQL Server中是一个很大的禁忌

• 它们会引发代价高昂的查询计划重新编译
• 创建和删除表也是要添加到流程中的成本高昂的操作
• 如果有大量数据传输到临时数据，由于缺少索引，您的操作将很慢。您可以在临时表上创建索引。但我永远不会为任何有大量记录的东西推荐一个临时表

您的另一种方法：创建并删除常规表只会产生相同的开销

另一种方法是：使用现有的表，用一个额外的列来扩充行，以区分哪些行属于可以使用的每个用户/会话。消除了创建/删除表的负担，但是，您需要对生成值以区分行的代码心存疑虑，并且您必须开发一种方法来维护表，以应对会话提前结束且有剩余（处理结束时未删除的行）的情况

我建议您重新考虑您的处理策略。有些替代方法与使用相关查询、派生表或表变量一样简单。看看：

---

---

编辑：创建和删除常规表的方法以及使用附加字段重新使用常规表的方法：两者都将生成查询计划重新编译，因为更改的数据量将触发表统计信息的重新评估。同样，您最好的方法是找到处理数据的替代方法。

您正在执行什么样的数据操作，以及处理多少数据

我会坚持使用临时表——对于大型数据集，我总是发现它是迄今为止最好的方法，而不仅仅是在SQL Server中。您可以尝试一个全局临时表（CREATETABLE##tablename），它的持续时间超出CREATE语句的范围

来自SQL Server联机丛书（2005）：

如果创建全局临时 表##employees中的任何用户 数据库可以使用此表。如果 没有其他用户使用此表 创建后，该表将被删除 断开连接时删除。如果 另一个用户使用该表 创建之后，SQL Server 断开连接并删除后删除它 在所有其他会议结束后 积极使用它

---

一个要考虑的问题是，你是否只能指望一个用户一次运行这个进程。如果同时有用户，则常规表选项可能会产生干扰。临时表对用户来说可能是唯一的。

-1#在这种情况下，临时表可能会更好。此外，与常规数据库相比，

tempdb

具有日志优化功能。表变量的存储方式与临时表完全相同，因此建议毫无意义。您链接到的那篇文章对于表变量的事务日志记录也是完全错误的。