このセクションでは，InnoDBテ，ブルの圧縮に関する一部の内部実装にいて詳細に説明します。ここで示す情報は,パフォーマンスを調整する際に役立つことがありますが,圧縮の基本的な使用を理解する必要はありません。

圧縮アルゴリズム

一部のオペレティングシステムでは，ファルシステムのレベルで圧縮が実装されています。一般に，ファイルは、可変サイズのブロックに圧縮される固定サイズのブロックに分割されるため、簡単に断片化されます。ブロック内部で何かが変更されるたびに、ブロック全体が再圧縮されてからディスクに書き込まれます。これらのプロパティーを使用すると、この圧縮方法が更新の多いデータベースシステムでの使用には適さなくなります。

MySQLでは，LZ77圧縮アルゴリズムが実装されている有名なZlibラeprブラリの支援を得て，圧縮が実装されています。この圧縮アルゴリズムは十分に発達し,強固であり,CPUの使用率とデータサイズの削減の両方の点で効率的です。このアルゴリズムは「損失なし」であるため，常に，元の非圧縮デ，タを圧縮形式から再構築できます。Lz77圧縮は，圧縮されるデタ内で繰り返される一連のデタを見けることで動作します。データ内の値のパターンによって,圧縮の効率性が決定されますが,多くの場合,一般的なユーザーデータは50%以上圧縮されます。

アプリケーションで実行される圧縮や,その他の一部のデータベース管理システムの圧縮機能とは異なり,InnoDBの圧縮は,ユーザーデータとインデックスの両方に適用されます。多くの場合,インデックスがデータベースの合計サイズの40 - 50%以上を占める可能性があるため,この相違点は重要です。デタセットの圧縮が正常に動作しているときは，InnoDBのデタファル(.idbファ▪▪ル)のサ▪▪ズが非圧縮サ▪▪ズの25%—50%，場合によってはそれよりも小さくなります。ワ，クロ，ドによっては,このようにデータベースを小さくすることにより,CPU使用率を少し増加させるだけでI / Oを削減してスループットを増加できます。innodb_compression_level構成オプションを変更すると，圧縮のレベルとCPUのオ，バ，ヘッド間のバランスを調整できます。

InnoDBデ，タストレ，ジと圧縮

InnoDBテ，ブル内のすべてのユ，ザ，デ，タは，Bリンデックス(クラスタ化された@ @ンデックス)を構成しているペ，ジに格納されます。その他の一部のデタベスシステムでは，このタプのンデックスは「ンデックス編成テ，ブル」と呼ばれます.ンデックスノド内の各行には，(ユザが指定した，またはシステムで生成された)主キの値およびテ，ブルのその他のすべてのカラムが含まれています。

InnoDBテ，ブル内のセカンダリ@ @ンデックスは,値のペア(インデックスキーと,クラスタ化されたインデックス内の行へのポインタ)を含むBツリーでもあります。実際は,ポインタはテーブルの主キーの値であり,インデックスキーおよび主キー以外のカラムが必要な場合に,クラスタ化されたインデックスにアクセスする際に使用されます。常に，セカンダリンデックスのレコドは，bリペジ上に収容される必要があります。

次のセクションで説明するように,(クラスタ化インデックスとセカンダリインデックスの両方の)Bツリーノードの圧縮は,長いVARCHAR、团，または文本カラムを格納するために使用されるオバフロの圧縮とは異なる方法で処理されます。

Bリペジの圧縮

Bリ，ペ，ジは頻繁に更新されるため，特別な処理が必要です。Bリノードが分割される回数を最小限にし、それらの内容を圧縮解除および再圧縮する必要性も最小限にすることが重要となります。

MySQLで使用される技術の1つでは,一部のシステム情報が非圧縮形式でBツリーノード内に保持されるため,特定のインプレース更新が容易になります。たとえば，これにより，圧縮操作なしで行に削除のマ，クを付け，その行を削除できます。

さらにMySQLでは,インデックスページが変更されたときに,不要な圧縮解除および再圧縮を回避しようと試みられます。システムの各bリペジ内には，ペジに行われた変更を記録するための非圧縮の「変更ログ」が保持されます。小さいレコードの更新および挿入は,ページ全体を完全に再構築する必要なしで,この変更ログに書き込まれる場合があります。

変更ログ用の領域を使い果たすと,InnoDBによってページが圧縮解除され,変更が適用され,ページが再圧縮されます。再圧縮に失敗すると(圧縮の失敗と呼ばれる状況),Bツリーノードが分割され,更新または挿入に成功するまでプロセスが繰り返されます。

OLTPアプリケーションなどで,書き込み負荷の高いワークロードでの頻繁な圧縮の失敗を回避するために,MySQLでは,ページ内にいくつかの空のスペース(パディング)が予約されている場合があります。これにより,変更ログがより早く埋められ,分割を回避するための十分な空き領域がまだある間にページが再圧縮されます。各ページに残されるパディングスペースの量は,システムでページ分割の頻度が追跡されるにつれて変化します。圧縮テ，ブルへの書き込みが頻繁に行われる高負荷のサ，バ，上では，innodb_compression_failure_threshold_pctおよびinnodb_compression_pad_pct_max構成オプションを調整すると，このメカニズムを微調整できます。

一般にMySQLでは,InnoDBテーブル内の各Bツリーページに2つ以上のレコードを収容できます。圧縮テ，ブルに対しては，この要件が緩和されました。Bリノードのリーフページには (主キーとセカンダリインデックスのどちらでも)、1 つのレコードのみが収容される必要がありますが、そのレコードはページごとの変更ログに非圧縮形式で収まる必要があります。innodb_strict_modeが在の場合は，创建表または创建索引の実行中に，MySQLによって行の最大サescズがチェックされます。行が収まらない場合は，“错误HY000:太大的行”というエラ，メッセ，ジが発行されます。

innodb_strict_modeがoffのときにテ，ブルを作成した場合に，後続の插入または更新ステートメントで圧縮済みページのサイズに収まらないインデックスエントリの作成が試みられると,その操作に失敗し,错误42000:行大小太大というエラーが表示されます。(このエラーメッセージは,レコードが長すぎるインデックスの名前を示すものでも,その特定のインデックスページ上のインデックスレコードの長さや最大レコードサイズを示すものでもありません)この問題を解決するには,ALTER TABLEを使用してテブルを再構築し，より大きな圧縮済みペジサズ(KEY_BLOCK_SIZE)を選択して，任意のカラムプリフィクスのROW_FORMAT =动态またはROW_FORMAT =紧凑を使用して圧縮を完全に無効にします。

Blob, varchar，および文本カラムの圧縮

InnoDBテ，ブルでは，主キ，の一部ではない团、VARCHAR，および文本カラムが，個別に割り当てられたオ，バ，フロ，ペ，ジに格納される場合があります。このようなカラムは，オフペ，ジカラムと呼ばれています。これらの値は，オ，バ，フロ，ペ，ジの片方向リストに格納されます。

ROW_FORMAT =动态またはROW_FORMAT =压缩で作成されたテ，ブルでは，カラムの長さおよび行全体の長さによっては，团、文本，またはVARCHARカラムの値が完全にオフペ，ジに格納される場合もあります。オフページに格納されるカラムでは,クラスタ化されたインデックスのレコードに,オーバーフローページへの20バイトのポインタのみがカラムごとに1つずつ含まれます。カラムがオフペ，ジに格納されるかどうかは，ペ，ジサ。行がクラスタ化されたインデックスのページ内に完全に収まらないほど長い場合は,クラスタ化されたインデックスページ上に行が収まるまで,MySQLによってオフページストレージに合った最長のカラムが選択されます。前述の注で示したように，行自体が圧縮済みペ，ジ上に収まらない場合は，エラ，が発生します。

古いバジョンのMySQLで作成されたテブルでは，ROW_FORMAT =冗余とROW_FORMAT =紧凑のみがサポ，トされている羚羊ファ@ @ル形式が使用されます。MySQLでは，これらの形式で、クラスタ化されたインデックスレコード内に团、VARCHAR，および文本カラムの最初の768バトが主キとともに格納されます。768年バイトのプリフィクスのあとには,残りのカラム値を含むオーバーフローページへの20バイトのポインタが続きます。

テ，ブルの形式が压缩である場合は，オバフロペジに書き込まれるすべてのデタが「そのまま」圧縮されます。。圧縮済みのオーバーフローページには、データ以外では特に、ページチェックサムを構成する非圧縮のヘッダーとトレーラ、および次のオーバーフローページへのリンクが含まれます。したがって、テキストデータを使用した場合に多く見られるように、データの圧縮性が高い場合は、長い团、文本，またはVARCHARカラムで非常に大幅なストレ，ジの節約が実現されます。一般に，JPEGなどのイメージデータはすでに圧縮されているため,圧縮テーブルに格納される利点がほとんど得られません。領域の節約がほとんどない,またはまったくない場合は,二重圧縮によってCPUサイクルが無駄になる可能性があります。

オバフロペジのサズはその他のペジと同じです。カラムの合計長が8 kバイトのみである場合でも,オフページに格納される10個のカラムを含む行で,10個のオーバーフローページが占有されます。非圧縮テブルでは，10個の非圧縮オバフロペジで160kバトが占有されます。ペジサズが8kの圧縮テブルでは，80kバトのみが占有されます。そのため,長いカラム値を含むテーブルでは,圧縮テーブル形式を使用すると効率性が高くなることが多くあります。

16 kの圧縮済みページサイズを使用すると,多くの場合,このようなデータが効率的に圧縮されることで,必要なオーバーフローページが少なくなる可能性があるため,Bツリーノード自体のページ数は非圧縮形式の場合と同じであるにもかかわらず,团、VARCHAR，または文本カラムのストレジおよびI/Oコストを削減できます。

圧縮とInnoDBバッファ，プ，ル

圧縮済みのInnoDBテブル(1K, 2K, 4，または8K)は，16Kバト(innodb_page_sizeが設定されている場合は，さらに小さいサズ)の非圧縮ペジに対応しています。ペ，ジ内のデ，タにアクセスするために，MySQLは，圧縮済みペ，ジがバッファ，プ，ル内にすでに存在しない場合，そのペ，ジをディスクから読み取ってから，その元の形式に圧縮解除します。このセクションでは,圧縮テーブルのページに関して,バッファープールがInnoDBで管理される方法について説明します。

I / Oを最小限にして,ページを圧縮解除する必要性を削減するために,バッファープールに圧縮済み形式と非圧縮形式の両方のデータベースページが含まれることがあります。その他の必要なデータベースページ用の空き領域を作成するために,MySQLではメモリー内に圧縮済みページを残しながら,バッファープールから非圧縮ページをエビクションできます。また,しばらくの間ページがアクセスされていない場合は,その他のデータ用に領域を解放するために,圧縮形式のページがディスクに書き込まれることもあります。したがって,そのときどきで,バッファープールに圧縮形式と非圧縮形式の両方のページが含まれている場合,圧縮形式のページのみが含まれている場合,どちらも含まれていない場合があります。

MySQLでは，ホット(頻繁にアクセスされる)データがメモリー内に滞在する傾向となるように,最近もっとも使用されていない(LRU)リストを使用して，メモリ，内に保持されるペ，ジおよび削除されるペ，ジが追跡されます。圧縮テーブルにアクセスすると、MySQL は適応型 LRU アルゴリズムを使用して、メモリー内の圧縮済みページと非圧縮ページの適切なバランスを実現します。この適応型アルゴリズムは、システムがI/OバウンドとCPUバウンドのどらの方式で実行されているかどうかの影響を受けやすくなります。この目的は、CPUの負荷が高いときにページを圧縮解除するために要する処理時間が長くなりすぎることを回避すること,および(メモリー内にすでに存在する可能性のある)圧縮済みページを圧縮解除するために使用できる予備のサイクルがCPUに備わっているときに過剰なI / Oが発生することを回避することです。システムがI / Oバウンドの場合,このアルゴリズムでは,その他のディスクページ用により多くの空き領域を作成することでメモリーが常駐になるように,ページの両方のコピーではなく,非圧縮コピーを削除することが優先されます。システムがCPUバウンドの場合，MySQLでは，「ホット」ページ用に使用できるメモリーが多くなり,圧縮形式でのみメモリー内のデータを圧縮解除する必要性が少なくなるように,圧縮済みページと非圧縮ページの両方を削除することが優先されます。

圧縮とInnoDBのRedoログファereplicationル

圧縮済みペ，ジがデタファルに書き込まれる前に,MySQLによってページのコピーが重做ログに書き込まれます(最後にデータベースに書き込まれた以降に再圧縮された場合)。これは，zlibライブラリがアップグレードされ,その変更によって圧縮済みデータとの互換性の問題が発生する可能性が低い場合でも,クラッシュリカバリ時に重做ログを使用できるかどうかを確認するために行われます。したがって，圧縮の使用時に，ログファ@ @ルのサesc escズを多少大きくすること，またはより頻繁にチェックポ@ @ントを発生させる必要性を多少多くすることが要求される可能性があります。ログファ@ @ルのサイズを大きくする量またはチェックポイントの頻度を多くする数は、再構成および再圧縮が必要となる方法で圧縮済みページが変更される回数によって異なります。

圧縮テーブルでは,重做ログおよびテーブルごとのテーブルスペースに使用されるファイル形式がMySQL 5.1以前とは異なることに注意してください。MySQL企业备份製品では，圧縮済みInnoDBテ，ブル用に，この最新の梭鱼ファ▪▪ル形式がサポ▪▪トされています。