SQL Server 2014でのテーブル圧縮の使用
SQL Serverでのテーブル圧縮に関する記事を読んでいます。私にとっては、圧縮されたテーブルをセットアップするのは非常に簡単であるように思われ、その利点は決定を容易にします。
私はこのコミュニティに相談して、知っておく必要がある落とし穴があるかどうかを確認したいと思いました。テーブル圧縮機能が見た目ほど単純ではないのではないかと心配しています。テーブルを圧縮テーブルに移行するときに不要な副作用はありますか？
私の経験では、考慮すべきことがいくつかあります。
- 場合によっては、おそらく圧縮設定を考慮しないメンテナンスタスクが原因で、インデックスとテーブルの圧縮がオフになっているため、インデックスを再構築するルーチンタスクを慎重に検討してください。
- スペースの節約は重要です
- 圧縮されたテーブル/インデックスに対するクエリがディスクからデータを読み取る場合、ディスクのI/O制限のため、非圧縮テーブルを読み取るクエリよりも（私の経験では）高速でした。
- ただし、ページが既にバッファープールにある場合、データの圧縮解除に追加のCPUが必要になるため、非圧縮データに比べてクエリが遅くなりました。
したがって、CPU、RAMおよびストレージ容量についての状況を考慮してください。優れた圧縮とクエリパフォーマンスの両方を提供する columnstoreインデックス を考慮することを忘れないでください。
テーブル圧縮を使用することの利点は、テーブルのサイズとともに増加します。テーブルが小さい場合、CPU時間の消費は、I/Oの削減のメリットよりも大きなペナルティになる可能性があります。また、バッファ用のメモリが少ない場合、パフォーマンスに大きな影響を与える可能性があります。次に、ページが頻繁に読み込まれて圧縮解除され、CPU使用率が増加します。ほとんどの場合、これは低いページ存続期間期待値（PLE）として示されます。要するに-それは依存します...
あまり知られていない1つの問題は、ページ圧縮がテーブルに対するデータ型変更操作のパフォーマンスに劇的な影響を与える可能性があることです。私の経験では、圧縮されていないテーブルで列をNULLからNOT NULLに変更するのはかなり高速ですが、ページ圧縮されたテーブルでの変更は、トランザクションログに書き込まれるテーブルのサイズの10倍以上を必要とする場合があります。場合によっては、圧縮されたテーブルを非圧縮として再構築し、データ型の変更を実行し、テーブルを再度圧縮して再構築する必要がありました。