● データ 圧縮は、ディスク の スペース を節約するために使う。

　ディスク の スペース を節約するために、データ を圧縮することがある。
　本稿では、文字列の圧縮を対象にして、画像 データ の圧縮は対象としない。

　データ 圧縮とは、以下の要件に合致する データ を圧縮する機能である。

　（1） [ 英文字属性では ] ブランク 状態 （HEX '40'） が 3 バイト 以上継続している。
　（2） [ 数値属性では ] ゼロ （HEX 'F0'） が 3 バイト 以上継続している。

　データ 圧縮を パフォーマンス の観点から判断すれば、以下の 2点が論点になる。

　（1） 1つの ブロック のなかに収納される レコード 件数が多くなる。
　（2） データ を拡張するための バッファ （expand-buffer） を用意しなければならない。

　
● データ を圧縮すれば、データ の ヒット 率が高まるというのは迷信である。

　I/O 単位は ブロック であり、アクセス 単位は ビュー である。
　1つの ブロック のなかに収納される レコード 件数が多くなるので、データ の ヒット 率が高くなると思われているが、データ を順次に読み込むなら、たしかにそうだが、ランダム な読み込みでは、あてにならない確率にすぎない。
　しかも、データ を順次に読む込むときに、すべての データ （レコード） が （後述する） 拡張 バッファ を経由するというのでは パフォーマンス が悪い。「ヒット 率が高くなる」 というのは、パフォーマンス の観点から言えば、迷信である。

　
● DB の高 パフォーマンス を実現したいなら、データ を圧縮しないほうがいい。

　 　データ を圧縮していれば、ブロック 単位に読み込まれた データ （複数の レコード） は拡張 バッファ に転送されて （ビットマップ 式などの手法を使って） 圧縮されている フィールド が判断され拡張されて、非圧縮の レコード 状態に変換されてから ビュー 単位に アクセス され、プログラム の演算が終了したら、拡張 バッファ を使って レコード が圧縮されてから、ブロック に転送される。すなわち、テーブル と プログラム の間では、通常の データ・バッファ （および、インデックス・バッファ） の操作に加えて、拡張 バッファ を経由する操作が割り込む。

　拡張 バッファ の経由は RDBMS に対して負荷を与える。
　負荷を小生が計測してみたら、最高 25 ％にも及んだ事例があったので──当然ながら、ブランク と ゼロ が多ければ多いほど負荷は高くなるが──、DB の パフォーマンス が低下する [ ただし、25 ％の負荷というのは RDBMS に対する負荷であって、パフォーマンス が、25 ％、低下するという意味ではない ]。