3

製品アイテムに関する情報を格納するテーブル（InnoDB）を設計しています。

アイテム->

  • item_id（PK）
  • 価格
  • 重さ
  • stock_count
  • category_id
  • 説明（BLOB、最大2K）

このテーブルは主に、特定のアイテムのすべてのデータをフェッチするために読み取られますが、説明フィールドだけを読み取ることができる場合もあります。アイテムのデータが頻繁に更新されることはなく、説明フィールドが含まれます。

2つのクエリがあります：

  • 読み取り操作を高速化するには、テーブルを2つの部分に分離する方がよいでしょうか。1つは固定幅のフィールドで、もう1つはblobの「説明」フィールドです。私が見逃している基本的な理解は、説明フィールドの可変長がアイテムデータのルックアップ時間に影響を与えるかどうかということだと思います。

  • たくさんのアイテムデータ、たとえば10Mを保持している場合、このテーブルの更新速度は、上記の分離されたテーブルと比較してどうですか。

4

1 に答える 1

2

InnoDB は、固定幅の行から何の利点も得られません。それが MyISAM の最適化です。

InnoDB では、長い BLOB/TEXT/VARCHAR カラムは、追加のストレージ ページにオーバーフローする可能性があります (バッファー プールはテーブルスペースと同じページ構成を持っているため、メモリも)。

行のプライマリ ページに収まる短い BLOB/TEXT/VARCHAR は、他の列と共にそこに存在します。オーバーフローした場合でも、既定の行形式 (COMPACT) には、このような大きな列の最初の 768 バイトが含まれます。

詳細については、http://www.mysqlperformanceblog.com/2010/02/09/blob-storage-in-innodb/を参照してください。

したがって、1 ページあたりの行数を増やすことに懸念がある場合は、テーブルを分割して、説明列を別のテーブルに格納できます。

InnoDB は更新時にログ ファイルに書き込み、ログ ファイルはテーブルスペースのようにページ単位で編成されないため、更新時にはさらに重要ではありません。後で、バッファー プール内の変更されたページがテーブルスペースに書き込まれますが、アプリケーションはそれを待つ必要はなく、バックグラウンドで行われます。

ただし、これはあなたが考えるほど大きなメリットではないかもしれません。おそらく、インデックスを使用してクエリがアクセスする必要がある行数を絞り込んで最適化する方が良い戦略です。

于 2013-02-21T20:21:59.507 に答える