翻译自:https://stackoverflow.com/questions/28820587
78 次
0

SQL サーバー 2008 R2。

次のような単純な更新コマンドを実行する

UPDATE [group_mtm] SET group = foobar where user in (u1,u2,u3,...u19)

クエリは 1 行しか更新しませんが、2 秒以上かかります。これは、多対多のジャンクションとして使用される 2 つの属性テーブルです。現在、テーブルには約 300 レコードしかありません。主キー = グループおよびユーザー属性の複合キー。

私はそれを調べるために統計を設定しました。クエリの実行には、ビジネスが関与していない他のテーブルが多数含まれています。

Table 'foobar'. Scan count 1, logical reads 21214, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 1664, logical reads 42674, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'mail_mtm'. Scan count 1, logical reads 428, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'event'. Scan count 1, logical reads 893, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'user'. Scan count 0, logical reads 91, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'addresses'. Scan count 1, logical reads 12, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'mail'. Scan count 1, logical reads 79, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'links'. Scan count 1, logical reads 18, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'group_mtm'. Scan count 20, logical reads 120, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(20 row(s) affected)

(1 row(s) affected)

私が考えることができる唯一のことは、foobar はインデックス付きビューであり、おそらくそれを維持するためにコストが費やされているということです。そのため、実行計画を確認しました。それは実際に機能します(ただし、コストはわずか 11% です)。

なぜ2秒以上かかるのですか?

私はここで何を見落としていますか?

実行計画では、イベントにインデックスを追加するようにアドバイスされていますが、イベントはここに含まれるべきではなく、コストはわずか 13% です。

何らかの理由で他のテーブルがこれに引き込まれていなければ、これは非常に速いはずだと思います。

インデックス付きビューが一般的な DB オーバーヘッドを増加させることについて、誰かが賢明なアドバイスをくれるでしょう。しかし、他のすべての操作は、インデックス付きビューによって提供される特定のクエリの検索を高速化するために、かなりのコストがかかるように思えます。

教えて; よろしくお願いします!

XML実行計画は大きすぎてテキストとして投稿できず、添付するオプションが表示されないため、pastebinで救助してください:http://pastebin.com/BgjBxLfc

4

1 に答える 1

0

これがすべての答えではないかもしれませんが、SQL クエリを拡張して、フィールド名をさらに修飾します: [テーブル].[フィールド]。「group」は group_mtm のフィールドだと思いますが、「foobar」テーブルをそれに割り当てようとしているように見えますか?

于 2015-03-02T23:10:38.433 に答える