17

SOを検索しているときに、矛盾する2つの回答（およびそれを述べたコメントでさえ）を見つけましたが、決定的な回答はありませんでした：

問題は、TEXT/BLOB フィールドをテーブルの外に格納すると、パフォーマンス上の利点があるかどうかです。

次のように仮定します。

  • 正しく SELECT します (必要に応じて TEXT/BLOB のみを選択し、SELECT * は使用しません)。
  • テーブルは適切にインデックス付けされ、意味があります (したがって、「インデックス付けするかどうか」は問題ではありません)。
  • データベースの設計は重要ではありません。これは、特定のデータベース設計の問題を解決するためではなく、この特殊なケースでの MySQL の動作を特定するための質問です。このデータベースにはテーブルが 1 つしかないとします (TEXT/BLOB が分離されている場合は 2 つ)。
  • 使用エンジン: innoDB (異なる結果を取得する場合は、他のものも興味深いでしょう)

この投稿では、TEXT/BLOB を別のテーブルに配置することは、既に間違った方法で SELECT を行っている場合にのみ役立つ (必要でない場合でも常に TEXT/BLOB を SELECT する) 場合にのみ役立つと述べています。とにかくTEXT / BLOBは別々に保存されるため、同じテーブルが基本的により良い解決策です（複雑さが少なく、パフォーマンスが低下しないなど）

TEXT 列を別のテーブルに移動することでメリットが得られるのは、通常、テーブルからすべての列を選択する傾向がある場合のみです。これは、最初の悪い習慣を補うために 2 つ目の悪い習慣を導入しているだけです。言うまでもなく、2 つの間違いは 3 つの左と同じではありません。

TEXT 列を持つ MySQL テーブル

ただし、この投稿には次のように記載されています。

テーブルに TEXT 列または BLOB 列がある場合、テーブルをメモリに格納できません

これは、テーブル内に TEXT/BLOB を配置するだけで、パフォーマンスが低下するということでしょうか?

MySQL varchar(2000) 対テキスト?

私の質問は基本的に次のとおりです。正しい答えは何ですか?

TEXT/BLOB を別のテーブルに格納することは本当に重要ですSELECTか?

または、テーブル内に TEXT/BLOB を配置しても、潜在的なパフォーマンス ヒットが発生しますか?

4

2 に答える 2

17

更新: Barracuda は、バージョン 5.7 以降のデフォルトの InnoDB ファイル形式です。

MySQL バージョンで利用可能な場合は、InnoDB Barracuda ファイル形式を使用します。

innodb_file_format=barracuda

ROW_FORMAT=DynamicMySQL 構成で(または) を使用してテーブルをセットアップし、Compressed実際に使用します。

これにより、InnoDB は BLOB、TEXT、およびより大きな VARCHAR を行ページの外に格納できるようになり、効率が大幅に向上します。詳細については、この MySQLperformanceblog.com ブログ記事を参照してください。

私が理解している限りでは、バラクーダ形式を使用すると、パフォーマンス上の理由から、TEXT/BLOB/VARCHAR を別のテーブルに格納することはできなくなります。ただし、適切なデータベースの正規化を念頭に置いておくことは常に良いことだと思います。

于 2012-12-17T15:49:11.027 に答える
6

パフォーマンスの向上の 1 つは、固定長のレコードを持つテーブルを持つことです。これは、varchar や text/blob のような可変長フィールドがないことを意味します。固定長レコードの場合、MySQL はサイズ オフセットを認識しているため、レコードの最後を「シーク」する必要はありません。また、X レコードをロードするために必要なメモリ量も認識しています。固定長のレコードを持つテーブルは、削除されたレコードから利用可能になったスペースを完全に再利用できるため、断片化の可能性が低くなります。MyISAM テーブルには、実際には、固定長レコードによる他の利点がいくつかあります。

innodb_file_per_table を使用していると仮定すると、tex/blob を別のテーブルに保持すると、テーブルが小さくなるため、ファイル システム キャッシュが使用される可能性が高くなります。

つまり、これはマイクロ最適化です。パフォーマンスを大幅に向上させるためにできることは他にもたくさんあります。たとえば、SSD ドライブを使用します。テーブルが非常に大きくなり、シャーディングを実装する必要がある場合、計算の日を押しのけるのに十分なパフォーマンスの向上は得られません。

「生のファイル システム」を使用するデータベースについては、はるかに高速であるにもかかわらず、もはや耳にしません。「Raw」とは、データベースがファイル システムをバイパスしてディスク ハードウェアに直接アクセスする場合です。オラクルはまだこれをサポートしていると思います。しかし、複雑さを増すだけの価値はありません。自分が何をしているのかを本当に理解する必要があります。私の意見では、テキスト/ブロブを別のテーブルに保存しても、パフォーマンスが向上する可能性があるため、複雑さが増すだけの価値はありません。それを利用するには、自分が何をしているのか、そしてアクセスパターンを知る必要があります。

于 2012-12-23T22:35:03.867 に答える