TSQL：在select with join中使用replace函数

背景。我正在使用SQL Server。我在数据库中有两个表：

Vendors(Id, Name, Description)
Products(Id, VendorId, Name, Description)

Id

列中的值在

Vendor

表中用前缀

'Id\

格式化

VendorId

列中的值在

Products

表中用前缀

'VEā

格式化

例如

产品中的
中的
'VE_001245'
指
供应商中的
'ID_001245'

（请不要建议改变这个概念，不要关心数据库方案，不要建议添加外键。所有这些都只是为了说明。）

问题：以下哪一个查询在性能方面最好，为什么

使用内部
选择中的
替换
功能：

select v.* from Vendors v
inner join
(
    select distinct replace(VendorId, 'VE_', 'ID_') as Id
    from Products
) list
on v.Id = list.Id


使用
-语句上的
中的

替换功能：

select v.* from Vendors v
inner join
(
    select distinct VendorId as Id
    from Products
) list
on v.Id = replace(list.Id, 'VE_', 'ID_')

---

编辑。每个表中只有聚集索引（按

Id

列）。每个表可以包含数百万行。

两个查询的性能几乎相同。在第一个查询中，排序执行两次，一次是在选择不同的记录时，另一次是在执行内部联接时，最后是一个合并联接以选择最终结果集。 而在第二次查询中，排序只执行一次，但执行的是哈希连接，这比合并连接更昂贵。

---

因此，在表上没有任何索引的情况下，这两个查询在性能方面是相同的。

我的猜测是2，就像1）我必须在整个产品列表上运行该函数，然后选择与之不同的。对于第二个，我只在一个不同的列表上运行函数（即，我必须在其上运行replace的行数应该更小）。但是很难知道，因为不知道数据编号、索引等是什么。既然您可以访问该架构，为什么不在实际执行计划显示和比较结果的情况下同时运行两者呢？是否可以添加（SQL2005+）@BogdanSahlean:否，我无法修改DB scheme。@dash我已更新了有关索引和估计表大小的详细信息的问题。当前表未填写。因此，我担心在填充表时实际的执行计划会发生变化。每个表中只有聚集索引（按Id列）。在这种情况下，取决于您可以选择查询的数量。第一个查询使用嵌套循环联接，这在数据较少时很好；第二个查询使用合并联接，这在处理大量数据时很好。