我正试图用"；复制数据"；Azure数据工厂中的管道。特别地，我使用"；使用查询"；选项与?AdfDynamicRangePartitionCondition挂钩，正如微软在这里的模式所建议的那样，在管道的Source选项卡中，复制操作通过查询本身中使用的分区键来并行化。
SQL Server数据库上的源代码由两个视图组成，分别具有约300k行和约3M行。此外，视图具有相同的查询结构，例如(伪代码(
with
v as (
select hashbyte(field1) [Key1], hashbyte(field2) [Key2]
from Table
)
select *
from v
视图查询的表也是如此。除此之外，视图查询相同数量的分区，这些分区的行数大致相等。
复制操作的意外行为(很可能是由于我方缺乏经验(是，对于查询较少行的视图，它持续的时间要长得多。事实上，具有约300k行的复制操作显示的吞吐量约为800KB/s，而具有约3M行的复制运算显示的吞吐量为约15MB/s(！(。最后，与从源代码读取操作相反，对blob存储的写入操作在这两种情况下都非常快。
我不希望任何人提供实际的解决方案，因为提供的信息有限，但我希望得到一些提示，说明在视图查询的行要少得多(大约一个数量级(的情况下，是什么会严重影响复制性能，考虑到视图下的表有相当数量的字段，以及相同的数据类型：视图查询的两个表都包含int、datetime和varchar数据类型。
提前感谢您的提醒。
对于任何可能偶然发现相同问题的人，我很有经验地发现，瓶颈是由SQL DB视图中存在的几个关键哈希计算引起的。事实上，当我删除这些内容(稍后在Azure Synapse Analytics(数据仓库(上计算(后，我观察到复制操作的性能得到了巨大提升。
当ADF中存在复制活动性能问题，并且根本原因不明显时(例如，如果源速度很快，但接收器被抑制，我们知道原因(——我将如何处理：
- 从Integration Runtime(IR((文档(开始。这可能是作业的并发问题、网络吞吐量问题，或者只是一个尺寸过小的VM(在自托管的情况下(。喜欢，>在我的产品ETL中，80%的问题都是由IR-s以某种方式引起的
- 复制源上和源上的复制活动行为；下沉从您的本地机器(理想情况下，从与IR相同环境的VM(查询视图，将平面文件写入blob，等等。我假设您已经这样做了，但再次进行观察很少会有什么坏处
- 测试复制活动的各种配置。更改
isolationLevel、partitionOption、parallelCopies和enableStaging将是我在这里的第一步。显然，这并不能解决问题的根本原因，但可以为你进一步深入研究指明方向 - 尝试搜索文档(此文档由@Leon提供，是一个良好的开端(。这应该是第一步，但是，我发现ADF文档有些缺乏
注意。这是基于我在数据工厂的个人经验
在这种情况下，提供一个特定的解决方案确实相当困难。