使用SQL临时表的速度与存储过程中的较长变量列表

Question

我有一个存储过程，其中包含约50个不同类型的变量的列表，这些变量作为不同组的一部分（声明，初始化，加载，计算，结果等）重复了大约8次。

为了避免重复，我想改用临时表（不是表变量，它不会带来我所追求的优势-推断类型）。

我已经读过，临时表可能从“在内存表中”开始，然后随着它们的增长而溢出到磁盘上，具体取决于内存量和许多其他条件。

我的问题是-如果我使用临时表存储和处理具有50个字段的一条记录，它会比使用50个变量慢吗？

Answer 1

除非需要为多行存储临时结果，否则我不会使用临时#Table。 我们的代码在某些存储过程中使用了很多变量。 在声明过程中进行初始化的功能有助于减少混乱。

Temp #Tables在查询编译方面有一些有趣的副作用。 如果您的存储过程调用了任何子过程，并且子proc中的查询都引用此#Table，则这些查询将在每次执行时重新编译。

另外，请注意，如果以任何方式修改temp #Table架构，则SQL Server将无法缓存表定义。 您将在引用该表的每个查询中产生查询重新编译惩罚。 同样，SQL Server将不断创建和删除表元数据，从而锤击各种系统表。

另一方面，如果您不调用子proc，并且不更改#Table模式，则它可能会执行OK。

但是从风格上讲，对我添加另一个联接到查询中只是为了获取要在WHERE子句中使用的变量，这对我没有意义。 换句话说，我宁愿看到很多这样的东西：

declare @id

select @id = ...

select tbl.id, ...
from tbl
inner join tbl2 ...
where tbl.id = @id

代替这个：

create table #VarTbl (...)

insert into #VarTbl (...) select ...

select tbl.id, ...
from tbl
inner join tbl2 ...
cross join #VariableTable
where tbl.id = VarTbl_ID

另一个想法：您可以将存储过程分解为逻辑操作组吗？ 这可能有助于提高可读性。 它还可以帮助减少查询重新编译。 如果需要重新编译一个子proc，则不会影响父proc或其他子proc。

Answer 2

不，它不会慢很多。 在正常使用情况下，您甚至可能会很难显示它的运行速度。

在这种情况下，我总是使用临时表。 我认为性能差异可以忽略不计，可读性和易用性更好。 如果超过10个变量，尤其是那些相关的变量，我通常会开始使用临时表。