約 4,000 万行のテーブルが 2 つあります。データベースのサイズは約 20GB で、ほとんどがこれら 2 つのテーブル用です。毎日、いくつかのデータ、つまり約 10M 行を削除する必要があります。そのため、バッチ削除を使用して、ログ ファイルを特定のサイズに抑えています。
もともと、テーブルの主キーはありません。ただし、テーブルごとに一意のクラスター化インデックスがあります。削除には永遠にかかります。つまり、仮想マシンで 500K 行を削除するには、約 2 ～ 3 時間かかります。* 削除する前に、インデックスが再構築されました。
ここで、一意のクラスター化インデックスを主キーに変換しました。2M 行を削除するには、約 20 ～ 30 分かかります。
主キーと一意のクラスター化インデックスに違いがあることは理解していますが、なぜパフォーマンスがそれほど異なるのでしょうか?
誰かがいくつかの洞察を持っていますか？
ありがとう
私の8ボールを転がす：クラスター化されていない主キーを宣言した場合（投稿から示唆されているように）、各バッチでインデックスの転換点に達する可能性が非常に高くなります。したがって、各バッチは 4,000 万行のフル スキャンを実行して、バッチ サイズを削除します。次に、次のバッチで再度フル スキャンを実行します。10M が削除されるまで、というように。クラスター化されたキーを使用すると、バッチは実際に削除される行のみをスキャンする必要があります (もちろん、バッチ削除基準は実際にクラスター化されたキーを使用すると思います...)。ご覧のとおり、推測を始めると多くの未知数があります...
しかし、最終的には... パフォーマンスに関する質問があり、パフォーマンスのトラブルシューティング手法を使用して調査する必要があります。実行計画、待機 stats、統計 ioを取得します。Waits や Queuesなどの方法論に従います。測定。ちょうど8ボールを転がしたばかりのインターネット上の誰かからの推測に耳を傾けないでください...
削除する前にインデックスを削除してから、後で再度追加することができます。私が間違っていなければ、削除するたびにインデックスが再編成されます。余分な時間がかかります。
ある削除操作の前にインデックスが非常に断片化されていたが、別の削除操作の前には断片化されていなかったようなものかもしれません。クラスター化された一意のインデックスはどの程度断片化されましたか? 次のような方法で削除する前にすべてのインデックスを再構築した後、ランタイムにまだ違いがあるかどうかを確認できますALTER INDEX ALL ON blah REBUILD
一意のクラスター化インデックスを作成するときに使用したオプション (具体的には、PAD_INDEX、STATISTICS_NORECOMPUTE、SORT_IN_TEMPDB、IGNORE_DUP_KEY、ALLOW_ROW_LOCKS、および ALLOW_PAGE_LOCKS は何に設定されていますか?)