这是一个悬而未决的问题，但我真的很想听听人们的意见。
我很少使用显式声明的临时表（表变量或常规 #tmp 表），因为我相信不这样做会导致更简洁、可读和可调试的 T-SQL。我还认为，在需要时（例如当您在查询中使用派生表时），SQL 可以比我更好地利用临时存储。
唯一的例外是数据库不是典型的关系数据库而是星型或雪花模式时。我知道最好首先将过滤器应用于事实表，然后使用生成的临时表从维度中获取值。
这是普遍的观点还是有人持反对意见？
临时表对于报告或 ETL 作业等复杂的批处理过程最有用。通常，您预计在事务应用程序中很少使用它们。
如果您正在使用涉及多个大型表（可能是报告）的联接进行复杂查询，查询优化器实际上可能无法一次优化它，因此临时表在这里成为一个胜利 - 它们将查询分解为一系列更简单的方法可以减少查询优化器搞砸计划的机会。有时，您的操作根本无法在单个 SQL 语句中完成，因此需要多个处理步骤才能完成该工作。同样，我们在这里讨论更复杂的操作。
您还可以为中间结果创建临时表，然后为该表建立索引，甚至可能在其上放置聚集索引以优化后续查询。这也可能是在不允许向数据库架构添加索引的系统上优化报表查询的一种快速而肮脏的方法。 SELECT INTO 对于此类操作很有用，因为它的日志记录最少（因此速度很快），并且不需要对齐选择和插入的列。
其他原因可能包括使用 CROSS APPLY 和 xpath 查询从 XML 字段中提取数据。通常，将其提取到临时表中然后在临时表上工作会更有效。对于某些任务，它们也比 CTE 快得多，因为它们具体化查询结果而不是重新评估查询。
需要注意的一件事是，临时表与查询引擎用于存储中间连接结果的结构完全相同，因此使用它们不会造成性能损失。临时表还允许使用集合操作执行多阶段任务，并使 T-SQL 代码中几乎（不完全是但几乎）不需要游标。
“代码味道”有点夸张，但如果我看到很多涉及临时表的简单操作，我会想知道发生了什么。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
