0

[Schema: key_id, x,y,z,...]一意で増分シードが 1 のキー ID 列を持つテーブル Aがあります。現在[schema: key_id, key_idOfA, x,y,z,....]、同様のスキーマを持つ A のバックアップであるテーブル B があります (差分テーブル B のみが独自のkey_idものを持ち、元のkey_id表Aの）。

where句に基づいてAからBにいくつかの行を転送するサービスがあります。このサービスを一度試してみたところ、A から B に行を転送することで問題なく動作しました。今度は、このサービスをもう一度確認するために、B から A に行 (key_idOfA、x、y、z、...) を転送する必要がありました。

ここでテーブルAの元のkey_idが失われないようにするために、最初に使用しました

SET IDENTITY_INSERT A ON

正常に機能した行を転送しました。乗り換え後に使った

SET IDENTITY_INSERT A OFF

サービスを再度実行すると、テーブル A からいくつかの行を取得するのに多くの時間がかかり、タイムアウトが発生します。正確に言えば、SQL Server Management Studio で 30,000 行を取得するのに 5 分かかります。サービスからのクエリは、3 分のタイムアウトによりタイムアウトになります。

テーブルのID挿入のオンとオフを切り替えるのは悪い習慣であることは承知していますが、これはテストベッドDBであり、本番DBでは決して行いません。

私の質問:

  1. クエリに非常に時間がかかっているため、インデックス作成が台無しになっていますか? それとも何か他の問題がありますか？

  2. インデックス作成を台無しにすることなく行を転送する別のアプローチをとることはできたでしょうか?

4

1 に答える 1

0

なぜ遅いのかを調べるためにできることは、実際のクエリプランを見てください。SSMS では、これは上部の [クエリ] メニューから実行され、[実際のクエリ プラン] (または CTRL-M) を選択します。後でクエリを実行すると、[結果とメッセージ] タブの横に追加のタブが表示されます。それは実行計画と呼ばれます。それを調べるときは、右端から始めなければなりません。そこからクエリが始まります。高いパーセンテージを探します。インデックス スキャンまたはテーブル スキャンが見られる場合、それらはより高速な方法であるインデックス シークよりも悪いものです。

テーブル/インデックス スキャンの割合が高い場合は、インデックスの最適化を試みてください。

インデックスをデフラグするために私が書いたスクリプトを見てみたいかもしれません: www.plixa.nl/fragment-an-index

役に立てば幸いです。そうでない場合は、お知らせください:)

于 2012-08-03T09:32:11.333 に答える