通过参数化查询更新链接服务器varchar列引发远程扫描和cursorfetch问题
核心根因
分布式查询元数据信任不足
SQL Server要将跨服务器更新操作下沉到远程节点执行，必须先确认远程表的列定义、约束、排序规则等元数据和本地认知完全一致。如果当前链接服务器使用的账号在远程实例上仅拥有UPDATE/SELECT等基础权限，没有VIEW DEFINITION或更高的表权限，本地优化器无法读取远程列的精确元数据，为了避免数据截断、排序规则不匹配导致的更新错误，会选择保守的执行策略：将整表数据拉到本地执行过滤和更新，再回写远程。
INT类型更新无异常是因为INT为定长数值类型，不存在排序规则、字符集转换的歧义，优化器无需额外元数据即可确认参数和列类型完全匹配，放心将过滤条件和更新操作推送到远程执行。字符类型（varchar/nvarchar）涉及排序规则、字符集兼容性校验，元数据可信度不足时优化器不会下沉执行计划。参数化查询的类型校验逻辑限制
ad-hoc查询使用字面量时，SQL Server在编译阶段就可以拿到字面量的精确长度、字符集、排序规则信息，和远程列元数据匹配成功后即可生成远程执行计划。而sp_executesql参数化查询的参数元数据是本地会话定义的，优化器无法确认该参数的排序规则和远程列的排序规则完全一致，即便手动修改为nvarchar类型，只要存在排序规则不匹配的可能性，优化器依旧会选择本地执行。sp_cursorfetch调用的触发逻辑
当优化器决定本地执行跨服务器更新时，为了保证更新的事务一致性，需要逐行锁定远程表的对应行，默认会调用API服务器游标，通过sp_cursorfetch分批拉取全表数据到本地，过滤出符合CustomerID = 619条件的行后再执行更新回写，就是你观测到的数百次游标调用、拉取120万行数据的来源。
永久修复方案
- 给链接服务器使用的登录账号授予远程服务器对应表的
VIEW DEFINITION权限，让本地优化器可以读取到远程列的精确元数据，消除元数据信任问题，优化器会自动生成远程执行的计划。 - 显式指定参数的排序规则和远程列的排序规则完全一致，参数定义时添加COLLATE属性，例如
@P1 varchar(4) COLLATE Chinese_PRC_CI_AS，消除字符类型隐式转换风险。 - 无需修改权限的替代方案：使用AT语法强制将更新语句推送到远程执行，同时保留参数化特性避免SQL注入：
EXEC ('UPDATE [CRM].[dbo].[Customers] SET [EyeColor] = ? WHERE [CustomerID] = ?', 'Blue', 619) AT [Hydrogen]
内容的提问来源于stack exchange，提问作者Ian Boyd
