11

localserver (SQL Server 2008 R2) にはsyn_view1、リンク サーバーを指すというシノニムがあります。remoteserver.remotedb.dbo.view1

この SLOW クエリの実行には20 秒かかります。

select e.column1, e.column2
from syn_view1 e
where e.column3 = 'xxx'
  and e.column4 = 'yyy'
order by e.column1

この FAST クエリの実行には1 秒かかります。

select e.column1, e.column2
from remoteserver.remotedb.dbo.view1 e
where e.column3 = 'xxx'
  and e.column4 = 'yyy'
order by e.column1

2 つのクエリの唯一の違いは、シノニムの存在です。明らかに、シノニムはクエリのパフォーマンスに影響を与えます。

SLOW クエリの実行プランは次のとおりです。

Plan                Cost %  Subtree cost
4 SELECT
I/O cost: 0.000000  CPU cost: 0.000000  Executes: 0  
Cost: 0.000000                  0.00    3.3521
    3 Filter
    I/O cost: 0.000000  CPU cost: 0.008800  Executes: 1  
    Cost: 0.008800              0.26    3.3521
        2 Compute Scalar
        I/O cost: 0.000000  CPU cost: 3.343333  Executes: 1  
        Cost: 0.000000          0.00    3.3433
            1 Remote Query
            I/O cost: 0.000000  CPU cost: 3.343333  Executes: 1  
            Cost: 3.343333      99.74   3.3433

FAST クエリの場合:

Plan            Cost %  Subtree cost
3 SELECT
I/O cost: 0.000000  CPU cost: 0.000000  Executes: 0  
Cost: 0.000000              0.00    0.1974
    2 Compute Scalar
    I/O cost: 0.000000  CPU cost: 0.197447  Executes: 1  
    Cost: 0.000000          0.00    0.1974
        1 Remote Query
        I/O cost: 0.000000  CPU cost: 0.197447  Executes: 1  
        Cost: 0.197447      100.00  0.1974

私の理解では、SLOW クエリでは、サーバーはリモート サーバーからすべてのデータをフェッチしてからフィルターを適用しますが (インデックスはありません)、FAST クエリでは、サーバーはリモート サーバーからフィルター処理されたデータをフェッチし、リモート インデックスを使用します。 .

高速で同義語を使用する方法はありますか? たぶん、リンクサーバーのセットアップですか？ローカルデータベースサーバー？

助けてくれてありがとう！

4

2 に答える 2

2

順序付けなしでデータをローカルサーバーの一時テーブルにダンプします。次に、順序で一時テーブルから選択します。注文はほとんどの場合キラーです。

于 2014-07-24T19:26:10.440 に答える
1

dba.stackexchange.comのこの投稿に対する受け入れられた回答では、リンク サーバーのアクセス権が制限されているため、リンク サーバーを介したクエリでパフォーマンスの問題が発生し、テーブル統計の可視性がローカル サーバーに制限される可能性があることに注意してください。これは、クエリ プランに影響し、パフォーマンスに影響する可能性があります。

抜粋：

そして、これが私が異なる結果を得た理由です。sysadmin として実行すると、注文 ID が 20000 を超える行がないことを示す完全な分散統計が取得され、推定値は 1 行でした。(オプティマイザーが統計からゼロ行を想定することは決してないことを思い出してください。) しかし、プレーン ユーザーとして実行すると、DBCC SHOW_STATISTICS はアクセス許可エラーで失敗しました。このエラーは伝播されませんでしたが、オプティマイザは統計がないことを受け入れ、デフォルトの仮定を使用しました。カーディナリティ情報を取得したため、リモート テーブルに 830 行あることがわかり、249 行と見積もられました。

于 2014-07-24T08:44:30.727 に答える