web-dev-qa-db-ja.com

MySQLrow_format圧縮vs動的

以下の理由により、「innodb_file_format」を「Antelope」から「Barracuda」bcozに変更しました。

  1. 行サイズの制限を回避するには
  2. 列インデックスのサイズ制限を回避するには

ファイル形式の変更を行っているときに、「動的」として「row_format」を選択しました。これは正常に機能しています。

しかし、データ圧縮のために「row_format」を「dynamic」から「compressed」に変更したいと思います。誰か教えてもらえますか

  1. Row_formatは、テーブルへのCOLUMNINDEXESおよびDATAINSERTSと関係がありますか？はいの場合、どちらが推奨され、その理由は何ですか？
  2. 圧縮形式はパフォーマンスの低下につながりますか？
mysqlinnodb
14
Murali Mopuru

DYNAMICまたはCOMPRESSEDを使用すると、InnoDBは、ページに完全に収まらないvarchar/text/blobフィールドをページ外に格納します。ただし、列ごとに20バイトしかカウントされない列を除いて、InnoDBの行サイズの制限は変更されていません。それでも、1行あたり約8000バイトに制限されています。

InnoDBは、列あたり767バイトのインデックスのみをサポートします。 innodb_large_prefix=1を設定し、DYNAMICまたはCOMPRESSED行形式を使用することで、この3072バイトを増やすことができます。

COMPRESSED行形式を使用しても、InnoDBはより長いインデックスをサポートしません。

パフォーマンスに関しては、これは「状況によって異なります」というケースの1つです。圧縮は通常、ストレージサイズと、圧縮および解凍するCPU負荷との間のトレードオフです。これは圧縮データを処理するためにもう少しCPUを必要とすることは事実ですが、データベースサーバーは通常I/Oを待機しており、CPUリソースに余裕があることを覚えておく必要があります。

ただし、常にではありません。バッファプールにあるデータに対して複雑なクエリを実行すると、I/OよりもCPUの制約を受ける可能性があります。したがって、データがRAMにどの程度収まるか、実行するクエリの種類、1秒あたりのクエリ数、ハードウェアの仕様など、多くの要因によって異なります。他の誰かがあなたのサーバー上のあなたのアプリケーションに答えることができるにはあまりにも多くの要因。あなたはそれをテストする必要があります。

あなたのコメントを再：

1つの可能性は、インデックスがバッファプールに適合していないことです。インデックス検索ですべてのSELECTクエリ中にページをロードしてページを削除する必要がある場合、パフォーマンスが大幅に低下します。 EXPLAIN分析では、インデックスがバッファプールに収まるかどうかはわかりません。

インデックス内の列の数や列のデータ型はわかりませんが、長いvarchar列にインデックスを付ける場合は、プレフィックスインデックスの使用（または列の長さの短縮）を検討する必要があります。

さらにRAMを取得し、バッファプールのサイズを増やすこともできます。

19
Bill Karwin

COMPRESSEDはデータを圧縮します。テキストは本当にうまく圧縮されます。私はいくつかのテーブルを持っていて、以前はDYNAMICを使用していましたが、COMPRESSEDに移動しました。

MySQL 5.7を使用しています

テーブル：

  • id（int）
  • some_other_id（int）
  • テキスト（ロングテキスト）-tf8mb4_unicode_ci〜500KB /行平均
  • update_at（int）
  • created_at（int）

DYNAMICと比較してCOMPRESSEDで使用するスペースが80％少なくなります。前：80Gb、後：16Gb大幅な節約ですが、そのデータはそれほど必要ありません。

他のテーブルはそれほど劇的ではありませんでしたが、〜50％保存いくつかのテキストフィールドがあります。例えば。もう1つは6.4Gb-> 3.1Gbで、150万行です。

私は、ほとんどが整数/ビットなどを保存する圧縮された小さなテーブルに変更していません。これらのテーブルはすでにスペースが小さいため、CPUを追加で使用する必要はありません。

6
Lukas Liesis