提高添加具有单个值的列的性能

Question

通过实验并且令人惊讶的是，我发现在大型表上左连接点表比将单个值简单地分配给列要快得多。点表是指 1x1（1 行 1 列）的表。

方法 1。简单的赋值，我的意思是这个（慢）：

SELECT A.*, 'Value' as NewColumn,
FROM Table1 A

方法 2。左连接点表，我的意思是（更快）：

WITH B AS (SELECT 'Value' as 'NewColumn')
SELECT * Table1 A
LEFT JOIN B
ON A.ID <> B.NewColumn

现在是我问题的核心。有人可以告诉我如何摆脱整个 ON 子句：

ON A.ID <> B.NewColumn?

检查连接条件似乎是不必要的浪费时间，因为表 A 的键不能等于表 B 的键。如果 t1.ID 的值与 'Value' 相同，它将从结果中丢弃行。删除该条件或可能将 <> 更改为 = 符号，似乎有更多空间来促进连接的性能。

2015 年 2 月 23 日更新
向性能专家提出的赏金问题。我的问答中提到的哪种方法最快。
方法 1 简单赋值，
方法 2 左连接点表，
方法 3 交叉连接积分表（感谢 Gordon Linoff 的回答）
方法 4 在赏金期间可能建议的任何其他方法。
正如我在 3 种方法中以秒为单位测量查询执行的经验时间一样 - 使用 LEFT JOIN 的第二种方法是最快的。然后是 CROSS JOIN 方法，最后是简单的赋值。令人惊讶的是。需要有所罗门之剑的表演专家来确认或否认。

Answer 1

我很惊讶这对于一个简单的表达式来说更快，但你似乎想要一个cross join：

WITH B AS (SELECT 'Value' as NewColumn)
SELECT *
FROM Table1 A CROSS JOIN
     B;

我使用此构造将“参数”放入查询中（可以轻松更改的值）。但是，我不明白为什么它会更快。如果表达式比较复杂（比如子查询或者非常复杂的计算），那么这个方法只计算一次。在原始查询中，它通常只会被评估一次，但也可能会针对每一行进行评估。

Answer 2

你也可以试试CROSS APPLY:

SELECT A.*, B.*,
FROM Table1 A
CROSS APPLY(SELECT 'Value' as 'NewColumn') B

Answer 3

你能不能尝试插入临时表而不是输出到屏幕：

SELECT A.*, 'Value' as NewColumn
INTO #Table1Assign
FROM Table1 A

和

WITH B AS (SELECT 'Value' as 'NewColumn')
SELECT * Table1 A
INTO #Table1Join
LEFT JOIN B
ON A.ID <> B.NewColumn

这将数据的实际传输和呈现到 SSMS 排除在外，这可能是由于网络速度变慢或客户端处理造成的。

当我使用 1M 行表运行此程序时，即使我为连接方法切换到 CROSS JOIN，我也始终使用简单的分配方法获得更好的性能。

Answer 4

我怀疑第二种方法会更快，三个选择和左连接。 首先，您应该使用各种样本数据重复测试相同的查询。

真实的场景是什么样的？

内连接肯定比左连接快。

这个怎么样？

Declare @t table(id int,c2 varchar(10))
INSERT INTO @T
select 1,'A' union all
select 2,'A' union all
select 3,'B' union all
select 4,'B' 

Declare @t1 table(nEWcOL varchar(10))
INSERT INTO @T1 Values('Value')

-- #Approach1
--SELECT * FROM @T outer apply
 --@t1

--Create index on both join column
 --#Approach2
SELECT * FROM @T A inner join
 @t1 b on a.c2<>b.nEWcOL

--#Approach3
Declare @value varchar(20)
Select @value= nEWcOL from @t1

select *,@value value from @t

Answer 5

评论的文字太多，所以添加了这个作为答案，尽管我实际上更多地添加到问题中（**）

不知何故，我认为这将是那些“视情况而定”的情况之一。我认为这在很大程度上取决于所涉及的行数，甚至更多取决于数据之后会发生什么。它是简单地返回，是在GROUP BY 或DISTINCT 中使用，我们是否进一步JOIN 或用它计算等等。

无论如何，我认为这 IS 是一个有趣的问题，因为我不得不找出在单行临时表中包含十几个“参数”比将它们预先分配给 12 个变量。很多很多个月前，给我的代码在我看来就像一个荒谬结构，所以我重写了它以使用@variables。这是在一个 +1000 行的存储过程中，需要从中挤出一些额外的性能。经过相当多的重构后，它的运行速度明显比更改前慢？！？！！

我从来没有真正理解为什么，当时只是再次恢复到旧版本。我最好的猜测是某种奇怪的参数嗅探与（自动创建的？）有关临时表的统计信息的组合；如果有人可以为您的问题带来一些启示，它可能也会导致我的答案 =)

（**：我意识到 SO 不是一个论坛，所以我先道歉，只是想说明观察到的 OP 行为并不完全是轶事）

Answer 6

Select * 不能在 SQL 上正确使用索引，您应该始终指定您的列。

除此之外我会使用

DECLARE @Value VARCHAR(30) = 'Value'
SELECT t.Id, t.C2, @Value NewColumn
FROM Table1 t