私のテスト環境では、4GBの本番データベースのコピーで、データの約20％をアーカイブし、SSMSから縮小して、最大空き容量が20％であることを示しました。
その結果、2.7GBのデータベースが恐ろしいパフォーマンスを発揮しました。特定のクエリは、本番環境で約0.5秒、現在テスト中の約11秒です。テストでクエリの全文部分を削除すると、実行時間は約2秒になります。
実際の実行計画は、本番とテストで同じです。
すべてのインデックスとフルテキストインデックスを再構築しました。パフォーマンスはほぼ同じです。複製以降、テストデータベースの実際のコンテンツは変更されていません。
私が犯人を探す場所についての考えはありますか（キーボードのすぐ後ろ以外に？:)
編集：わかりました。プロセスを3回繰り返しましたが、毎回同じ結果になりました...ただし、非アクティブなレコードをアーカイブするとすぐに、シュリンクを実行する前にパフォーマンスが低下します。アーカイブの0秒前、18秒後。いくつかのインデックスを再構築した後、7秒戻ってください。アーカイブプロセス：
- 新しい「アーカイブ」DBを作成します
- 削除する3種類のキーを識別し、それらをテーブル変数に格納します
- 20個のテーブルからこれらの3つのキーの「アーカイブ」DBへの選択を実行します
- これらの3つのキーの20個の「ライブ」テーブルから行を削除しました。
それでおしまい。アーカイブ後、実行プランを見ると、最初の操作であるクラスター化インデックススキャンに40％の時間が費やされています。
これを削除して、SQLサイトに質問を言い換えて再投稿します。