开放赏金：
好的，大家，老板需要一个答案，我需要加薪。这似乎不是一个冷缓存问题。
更新： 我已经按照下面的建议去做了，但都没有效果。然而，客户端统计数据提供了一组有趣的数字。
#temp vs @temp 插入、删除和更新语句的数量 0 vs 1
插入、删除或更新语句影响的行数 0 vs 7647
选择语句的数量 0 vs 0
选择语句返回的行数 0 vs 0
事务的数量 0 vs 1
最有趣的是受影响的行数和事务的数量。提醒一下，下面的查询返回相同的结果集，只是以不同的表格样式呈现。
以下查询基本上在做相同的事情。它们都选择一组结果（约7000个），并将其填充到临时表或变量表中。在我的看法中，变量表@temp应该比临时表#temp更快地创建和填充，但第一个示例中的变量表需要1分15秒才能执行，而第二个示例中的临时表只需要16秒。
有人能给出解释吗？
更新： 我已经按照下面的建议去做了，但都没有效果。然而，客户端统计数据提供了一组有趣的数字。
#temp vs @temp 插入、删除和更新语句的数量 0 vs 1
插入、删除或更新语句影响的行数 0 vs 7647
选择语句的数量 0 vs 0
选择语句返回的行数 0 vs 0
事务的数量 0 vs 1
最有趣的是受影响的行数和事务的数量。提醒一下，下面的查询返回相同的结果集，只是以不同的表格样式呈现。
以下查询基本上在做相同的事情。它们都选择一组结果（约7000个），并将其填充到临时表或变量表中。在我的看法中，变量表@temp应该比临时表#temp更快地创建和填充，但第一个示例中的变量表需要1分15秒才能执行，而第二个示例中的临时表只需要16秒。
有人能给出解释吗？
declare @temp table (
id uniqueidentifier,
brand nvarchar(255),
field nvarchar(255),
date datetime,
lang nvarchar(5),
dtype varchar(50)
)
insert into @temp (id, brand, field, date, lang, dtype )
select id, brand, field, date, lang, dtype
from view
where brand = 'myBrand'
-- takes 1:15
vs
select id, brand, field, date, lang, dtype
into #temp
from view
where brand = 'myBrand'
DROP TABLE #temp
-- takes 16 seconds