8

私はこのクエリを持っています

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

これは、1つの行を選択して更新するのに23秒かかります

しかし、openqueryを使用する場合（これは使用したくありません）、0.5秒しかかかりません。

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 に答える