作为长期和DMS打交道的老玩家，特别理解你这种从13分钟涨到1小时以上的崩溃——毕竟之前靠ADF带NOLOCK的查询跑的顺顺的，换了DMS反而卡壳，确实闹心。下面给你几个亲测有效的方法来在DMS里实现类似NOLOCK的效果：

方法一：通过源端点的额外连接属性全局启用（最推荐） #

这是最简单的全局配置方式，相当于给所有从SQL Server源端发起的查询都加上NOLOCK的隔离级别：

• 在创建或修改SQL Server源端点时，找到**“额外连接属性（Extra Connection Attributes）”**这个配置项
• 输入参数：READUNCOMMITTED=1
• 原理：这个参数会让DMS的源端连接使用READ UNCOMMITTED隔离级别，和你在查询里加WITH (NOLOCK)的效果完全一致——查询时不会对源表加共享锁，避免和其他业务操作的阻塞，直接提升读取速度。

方法二：针对单个表用自定义SQL查询加NOLOCK #

如果不想全局生效，只想给特定表加NOLOCK，可以在DMS任务的表映射里配置自定义查询：

1. 打开你的DMS任务，进入**“表映射（Table mapping）”**页面
2. 找到要配置的表，选择**“使用自定义选择查询（Use custom select query）”**
3. 编写带NOLOCK的查询，比如：

   SELECT Column1, Column2, Column3 
   FROM dbo.YourTargetTable WITH (NOLOCK)
   

   注意：自定义查询必须返回和原表完全一致的列名、数据类型，不能包含ORDER BY、TOP这类会改变结果集的语句，否则DMS任务可能报错或者数据同步异常。

重要提醒：使用NOLOCK/READ UNCOMMITTED的风险 #

虽然能显著提升速度，但还是要再啰嗦一句：READ UNCOMMITTED隔离级别会允许读取到源端未提交的事务数据（也就是脏读）。既然你之前用ADF的时候已经在用NOLOCK，想必业务上是能接受这个风险的，但如果你的迁移场景对数据一致性要求极高（比如金融类核心数据），一定要先评估再启用。

最后，配置完记得重启DMS任务让设置生效，跑一次测试看看性能是不是回到之前的水平——我之前帮几个客户这么配置后，迁移时间直接砍到原来的20%以内，应该能解决你的问题！