ADF复制活动设置批量大小后速度逐步变慢，寻求技术解析

这种“初始快、后续越跑越慢”的批量加载问题，在Azure SQL Data Warehouse（现Synapse SQL）与ADF的组合场景里并不少见，结合你提到的同环境跨库复制背景，我从几个核心方向拆解下可能的原因和对应方案：

1. 目标端Synapse SQL的资源与事务瓶颈 #

Synapse SQL作为MPP架构，批量写入时容易因资源不足或事务开销累积拖慢速度：

• 排查DWU资源使用率：登录Azure门户查看Synapse SQL的监控指标，重点看CPU、IO、日志写入的使用率是否随批次推进持续走高。如果DWU已跑满，可以临时调高DWU档位（比如从DW100c升级到DW200c）测试，观察速度是否回升。
• 缓解事务日志压力：批量写入会产生大量日志，当日志文件增长过快或备份跟不上时，会触发IO等待。可以检查Synapse的日志空间使用情况，确保日志备份策略为实时触发；也可以考虑让ADF使用COPY INTO命令替代默认批量插入——这个命令针对Synapse的写入做了专门优化，日志开销更低。
• 优化列存储索引开销：如果目标表用了聚集列存储索引（CCI），25000条的小批次插入会先存在行存储的delta store中，随着delta store内数据累积，后续插入的合并、压缩开销会急剧上升。你可以尝试把批量大小调整到10万-15万条（接近CCI行组的最佳压缩阈值），或者在复制完成后手动重建列存储索引。

2. 源端Azure SQL暂存库的查询性能退化 #

如果是增量加载，后续批次可能面临查询效率下降的问题：

• 检查增量查询的执行计划：把ADF用于读取增量数据的SQL语句单独拿到源SQL库执行，查看执行计划是否出现表扫描、键查找等高开销操作。如果有，给增量过滤字段（比如更新时间戳）创建非聚集索引。
• 更新源表统计信息：源表频繁做增量写入后，统计信息可能过时，导致SQL Server生成低效的执行计划。执行UPDATE STATISTICS [schema].[table]更新统计信息后再测试复制速度。

3. ADF复制活动的配置优化 #

ADF默认的批量复制逻辑可能存在累积开销，调整以下参数试试：

• 减少事务提交次数：如果ADF每批次提交一次事务，大量小事务会产生额外的日志和锁开销。在复制活动的Sink设置中，将Auto commit设为False，同时设置匹配批量大小（或更大）的Commit size，降低提交频率。
• 启用并行复制：在复制活动的Copy behavior中开启Parallel copy，根据源端资源情况设置并行度（比如4-8），让多个批次同时读取和写入，分摊单批次压力。
• 避免隐式数据转换：如果源表与目标表的字段类型不匹配（比如源端varchar转目标端nvarchar），随着数据量增加，转换开销会逐步累积。确保两端字段类型完全一致，消除隐式转换。

4. 网络与存储层的潜在瓶颈 #

即便在同一环境，也需要排除底层资源的问题：

• 检查存储IO延迟：查看源SQL库和目标Synapse的存储IO延迟指标，若延迟持续超过10ms，可能是存储层瓶颈。可以考虑将源库存储升级为Premium SSD，或检查Synapse的临时存储是否被占满——临时存储是本地SSD，满了会自动切换到远程存储，速度会骤降。
• 排查集成运行时资源：如果使用默认Azure集成运行时，查看其CPU、内存使用率是否跑满。可以创建专用集成运行时，配置更高核心数，避免资源竞争。

快速定位的验证步骤 #

你可以先做几个小测试缩小问题范围：

1. 将批量大小改为10万条，跑一次小批量数据，观察速度是否稳定。
2. 临时禁用目标表的所有索引和约束后复制数据，若速度恢复正常，说明是索引/约束的开销问题。
3. 用COPY INTO命令手动导入一批数据，对比ADF的复制速度，判断是ADF配置问题还是Synapse本身的写入性能问题。

内容的提问来源于stack exchange，提问作者DhruvJoshi