8

我有这个查询

UPDATE linkeddb...table SET field1 = 'Y' WHERE column1 = '1234'

选择和更新一行需要 23 秒

但是如果我使用 openquery（我不想这样做），那么它只需要半秒钟。

我不想使用 openquery 的原因是我可以安全地将参数添加到我的查询中，并且可以避免 SQL 注入。

有谁知道它运行如此缓慢的任何原因？

4

4 回答 4

9

这是一个替代方案。在远程服务器上创建一个存储过程以执行更新，然后从本地实例调用该过程。

/* 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'
于 2010-12-08T17:25:16.427 回答
4

如果您正在寻找原因，这里有一个来自Linchi Shea 博客的可能性：

要在链接服务器上使用表时创建最佳查询计划，查询处理器必须具有来自链接服务器的数据分布统计信息。对表的任何列具有有限权限的用户可能没有足够的权限来获取所有有用的统计信息，并且可能会收到效率较低的查询计划并体验到较差的性能。如果链接服务器是 SQL Server 的一个实例，要获取所有可用统计信息，用户必须拥有该表，或者是链接服务器上 sysadmin 固定服务器角色、db_ownerfixed 数据库角色或 db_ddladmin 固定数据库角色的成员。

（由于 Linchi 的帖子，此说明已添加到最新的 BooksOnline SQL 文档中）。

换句话说，如果链接服务器设置为具有有限权限的用户，则 SQL 无法检索表的准确统计信息，并且可能会选择较差的方法来执行查询，包括检索所有行。

这是有关链接服务器查询性能的相关 SO 问题。他们的结论是：使用 OpenQuery 以获得最佳性能。

更新：来自 Linchi 博客的一些关于链接服务器性能的优秀文章。

于 2010-12-08T19:19:56.807 回答
2

column1 是主键吗？可能不是。尝试使用主键（其中 PK_field=xxx）选择要更新的记录，否则（有时？）将读取所有记录以查找要更新的记录的 PK。

于 2010-11-18T11:50:55.970 回答
1

column1 是 varchar 字段吗？这就是为什么你用单引号括住值 1234 ？或者这只是你问题中的一个错字？

于 2010-11-18T12:39:36.490 回答