テーブルを圧縮しない場合
2つのサーバーがあります。 1つだけ圧縮しましたが、この小さなプロジェクトを引き継ぎました この男は、いくつかのテーブルは適切な候補ではないと言っています 。他の多くの場合と同様に、パフォーマンスは-クリティカル-です。一部のテーブルを圧縮してはならないというのは正確ですか？もしそうなら、探すための一般的なしきい値は何ですか？私は彼のスクリプトを実行して、各オブジェクトの読み取り/書き込みをチェックしましたが、これは履歴のようであり、時間枠内で発生したものではないため、これは正確な測定方法ではない可能性があります。
SQL CATチームが作成した このホワイトペーパー もご覧ください。誰もがその文書を誰がレビューしたかに注意してください。それは非常によく書かれています。
ホワイトペーパーでは、データ圧縮について説明しているため、他のデータよりも圧縮率が高いデータがあることが説明されています。 アプリケーションワークロードに関するセクションには、いくつかの質問に関する情報が含まれていると思います。データ圧縮を使用した場合のパフォーマンスへの影響について説明します。私のアドバイスは、それをテストすることです。それがアプリケーション/システムに利益をもたらすか、害を及ぼすかどうかを確実に知る唯一の方法です。
ホワイトペーパーのスニペットは、データ圧縮の恩恵を受けていない一部のデータを示しています。
ほとんどの値が特定のデータ型に割り当てられたすべてのバイトを必要とする、数値または固定長の文字データ型の列
繰り返しデータが少ない
繰り返さないプレフィックスを持つ繰り返しデータ
行外に保存されたデータ
FILESTREAMデータ
Shawnの回答に付け加えておきますが、書き込み（更新、挿入、削除）が頻繁に行われるテーブルも候補としては適していません。トランザクションごとに圧縮を適用するには時間がかかるためです。例えば。新しいデータを受け入れる前にステージングテーブルを圧縮しないでください。データを圧縮テーブルにロードするよりも、データをロードして後で圧縮する方が高速です。