Sql server SSIS中的合并联接转换和查找转换之间有什么区别？

您好，我是SSIS软件包的新手，在编写软件包的同时阅读它们

我需要将DTS转换为SSIS包，需要对来自不同数据库的两个源执行连接，我想知道使用查找或合并连接的更好方法是什么

---

从表面上看，他们似乎非常相似。“合并联接”要求先对数据进行排序，而“查找”则不要求这样做。任何建议都会很有帮助。谢谢。

合并联接允许您基于一个或多个条件联接到多个列，而查找的限制更大，因为它仅基于一些匹配的列信息获取一个或多个值——将对数据源中的每个值运行查找查询（尽管SSIS将缓存数据源，如果可以的话）

这实际上取决于两个数据源包含的内容以及合并后希望最终数据源的外观。您能否提供有关DTS包中模式的更多详细信息

---

另外要考虑的是性能。如果使用不当，每一个连接都可能比另一个慢，但这又取决于您拥有的数据量和您的数据源架构。

合并连接旨在产生类似于SQL中连接工作方式的结果。查找组件的工作方式与SQL联接不同。下面是一个结果不同的例子

如果输入1（例如发票）和输入2（例如发票行项目）之间存在一对多关系，则希望这两个输入组合的结果包括单个发票的一行或多行

通过合并联接，您将获得所需的输出。对于查找，输入2是查找源，无论输入2中存在多少行，每个发票的输出都是一行。我不记得输入2中的哪一行会出现数据，但我很确定您至少会收到重复数据警告

因此，每个组件在SSI中都有自己的角色。

屏幕截图#1显示了一些区别

合并连接转换

和

查找转换

的要点

关于查找：

CREATE TABLE [dbo].[ItemAmount](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [ItemNumber] [nvarchar](30) NOT NULL,
    [Price] [numeric](18, 2) NOT NULL,
    [Discount] [numeric](18, 2) NOT NULL,
    [CalculatedAmount] [numeric](18, 2) NOT NULL,
CONSTRAINT [PK_ItemAmount] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO

CREATE TABLE [dbo].[ItemDiscountInfo](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [ItemNumber] [nvarchar](30) NOT NULL,
    [Discount] [numeric](18, 2) NOT NULL,
CONSTRAINT [PK_ItemDiscountInfo] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO

CREATE TABLE [dbo].[ItemPriceInfo](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [ItemNumber] [nvarchar](30) NOT NULL,
    [Price] [numeric](18, 2) NOT NULL,
CONSTRAINT [PK_ItemPriceInfo] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO

如果您希望根据源1输入在源2中查找匹配的行，并且知道每个输入行只有一个匹配，那么我建议使用查找操作。例如，如果您希望查找匹配的

订单Id

和

客户编号

，则查找是更好的选择

关于合并联接：

CREATE TABLE [dbo].[ItemAmount](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [ItemNumber] [nvarchar](30) NOT NULL,
    [Price] [numeric](18, 2) NOT NULL,
    [Discount] [numeric](18, 2) NOT NULL,
    [CalculatedAmount] [numeric](18, 2) NOT NULL,
CONSTRAINT [PK_ItemAmount] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO

CREATE TABLE [dbo].[ItemDiscountInfo](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [ItemNumber] [nvarchar](30) NOT NULL,
    [Discount] [numeric](18, 2) NOT NULL,
CONSTRAINT [PK_ItemDiscountInfo] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO

CREATE TABLE [dbo].[ItemPriceInfo](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [ItemNumber] [nvarchar](30) NOT NULL,
    [Price] [numeric](18, 2) NOT NULL,
CONSTRAINT [PK_ItemPriceInfo] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO

如果要执行联接，如从

Customer

表中给定客户的

Address

表中获取所有地址（家庭、工作、其他），则必须使用合并联接，因为该客户可以有一个或多个与其关联的地址

要比较的示例：

CREATE TABLE [dbo].[ItemAmount](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [ItemNumber] [nvarchar](30) NOT NULL,
    [Price] [numeric](18, 2) NOT NULL,
    [Discount] [numeric](18, 2) NOT NULL,
    [CalculatedAmount] [numeric](18, 2) NOT NULL,
CONSTRAINT [PK_ItemAmount] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO

CREATE TABLE [dbo].[ItemDiscountInfo](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [ItemNumber] [nvarchar](30) NOT NULL,
    [Discount] [numeric](18, 2) NOT NULL,
CONSTRAINT [PK_ItemDiscountInfo] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO

CREATE TABLE [dbo].[ItemPriceInfo](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [ItemNumber] [nvarchar](30) NOT NULL,
    [Price] [numeric](18, 2) NOT NULL,
CONSTRAINT [PK_ItemPriceInfo] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO

下面的场景演示了

合并联接

和

查找

之间的性能差异。这里使用的数据是一对一连接，这是它们之间唯一可以比较的常见场景

我有三个表，分别名为

dbo.ItemPriceInfo

，

dbo.ItemPriceInfo

和

dbo.itempount

。SQL脚本部分提供了这些表的创建脚本

表

dbo.ItemPriceInfo

和

dbo.ItemDiscountInfo

都有13349729行。这两个表的公共列都是ItemNumber。ItemPriceInfo具有价格信息，ItemDiscountInfo具有折扣信息。屏幕截图#2显示了每个表中的行数。屏幕截图#3显示了前6行，以了解表中的数据

我创建了两个SSIS包来比较合并联接和查找转换的性能。两个包都必须从表

dbo.ItemPriceInfo

和

dbo.ItemDiscountInfo

中获取信息，计算总金额并将其保存到表

dbo.ItemAmount

第一个包使用了

mergejoin

转换，在内部使用了内部连接来组合数据。屏幕截图#4和#5显示了示例包执行和执行持续时间。执行基于合并加入转换的包花费了

05

分钟

14

秒

719

毫秒

第二个包使用了带完全缓存的

查找

转换（这是默认设置）。creenshots#6和#7显示样本包执行和执行持续时间。执行基于查找转换的包花费了

11

分钟

03

秒

610

毫秒。您可能会遇到警告消息信息：

缓冲区管理器已分配nnnnn字节，即使已检测到内存压力并且多次尝试交换缓冲区失败。

下面是一个关于如何计算查找缓存大小的示例。在此包执行期间，尽管数据流任务完成得更快，但管道清理花费了大量时间

这并不意味着查找转换不好。只是它必须被明智地使用。我经常在我的项目中使用它，但我也没有每天处理1000多万行的查找。通常，我的作业处理200到300万行，因此性能非常好。高达1000万行，两行都表现同样出色。大多数时候我注意到的是，瓶颈原来是目标组件，而不是转换