我有这个问题
UPDATE linkeddb...table SET field1 = 'Y' WHERE column1 = '1234'
选择和更新一行需要 23 秒
但如果我使用 openquery（我不想这样做），那么它只需要半秒钟。
我不想使用 openquery 的原因是我可以安全地将参数添加到我的查询中并避免 SQL 注入。
有人知道它运行如此缓慢的任何原因吗？
【问题讨论】：
标签： asp.net sql sql-server linked-server openquery
这里有一个替代方案。在远程服务器上创建一个存储过程以执行更新，然后从本地实例调用该过程。
/* On remote server */
create procedure UpdateTable
@field1 char(1),
@column1 varchar(50)
as
update table
set field1 = @field1
where column1 = @column1
go
/* On local server */
exec linkeddb...UpdateTable @field1 = 'Y', @column1 = '1234'
【讨论】：
如果您正在寻找为什么，Linchi Shea's Blog 提供了一种可能性：
创建最佳查询计划时 您正在使用链接的表格 服务器，查询处理器必须有 数据分布统计 链接服务器。有限制的用户 任何列的权限 表可能没有足够的 获得所有有用的权限 统计数据，可能会收到更少 高效的查询计划和体验 表现不佳。如果链接 server 是 SQL Server 的一个实例，用于 获得所有可用的统计数据， 用户必须拥有该表或成为成员 sysadmin 固定服务器角色的 db_ownerfixed 数据库角色，或 db_ddladmin 固定数据库角色 链接服务器。
（由于 Linchi 的帖子，此说明已添加到最新的 BooksOnline SQL 文档中）。
换句话说，如果链接服务器设置为具有有限权限的用户，则 SQL 无法检索表的准确统计信息，并且可能会选择糟糕的方法来执行查询，包括检索所有行。
这是关于链接服务器查询性能的related SO question。他们的结论是：使用 OpenQuery 以获得最佳性能。
更新：来自 Linchi 博客的一些 additional excellent posts 关于链接服务器性能的信息。
【讨论】：
column1 是主键吗？可能不是。尝试使用主键（其中 PK_field=xxx）选择要更新的记录，否则（有时？）将读取所有记录以查找要更新的记录的 PK。
【讨论】：
column1 是 varchar 字段吗？这就是为什么你用单引号括住值 1234 ？或者这只是您问题中的一个错字？
【讨论】：