2

議論のために、MySQL テーブル内の非常に単純なファイルシステムを表現しようとしているとしましょう。これはまさに私がやっていることではないことに注意してください。質問の簡単な基礎になります。ですから、ファイルを保存するためのより良い方法を私に言わないでください。テーブルのスキーマは次のとおりです。

varchar path
varchar filename
blob content

上記のスキーマの問題点は、クエリが必ずしもコンテンツ フィールドを必要としない場合にパフォーマンスが低下することです。これは、コンテンツ フィールドが大きくない可能性があるためです。たとえば、特定のパス内のすべてのファイルを一覧表示するクエリを実行する場合、MySQL エンジンは (ファイル名フィールドを読み取るために) where 句に一致する各行をメモリに読み込みます。つまり、クエリには不要なこのコンテンツをメモリにロードする必要があるため、パフォーマンスが低下します。

この問題の一般的な解決策は、常に ID によって直接アクセスされる別のテーブルにコンテンツを移動することです。このアプローチの問題点は、挿入と選択が複雑になることです。コンテンツが 1 つの行に直接関連付けられていることは、すぐにはわかりません。

それで、私の質問（最後に！）はこれです。ブロブをスキーマ内に残し、特に要求された場合にのみ MySQL に取得させる方法はありますか? 列に配置できる代替ストレージ エンジンまたは修飾子があるかどうか疑問に思っています。ありがとう！

4

1 に答える 1

1

簡単な答えは実際にはありません（少なくとも、私が今まで見たことがない）。テーブルデータは特定の方法でディスク/メモリに保存され、それにアクセスすると常にBLOBコンテンツのペナルティが発生します。

速度を上げるのに役立つアプローチの1つは、既に配置されている場合とされていない場合がありますが、インデックスを使用するか、pathまたはfilenameそれらに基づいてクエリを実行する場合です。もちろん、挿入を開始するデータが多いほど、インデックスの最適化に関係なく、クエリの実行にかかる時間が長くなります。

個人的には、避けたいと思っている解決策を採用することをお勧めします。これは頻繁に使用されるアプローチであり、実際には複雑さを増すことはありません。これは単一の追加ステートメントであり、、または2番目のステートメントを使用してデータを取得INSERTできます。SELECTJOINSELECT

「コンテンツが単一の行に直接添付されていることはすぐにはわかりません」というステートメントについては、システムを設計しているのはあなたです。したがって、コンテンツが別のテーブルの行に添付されていることは非常に明白です。テーブルと列に十分な名前を付ければ、システムで作業している他の人にも（願わくば）明白になるはずです。files（with 、、）や（with id、 ）など。pathfilenamefile_contentsfile_idcontent

于 2012-10-03T18:26:11.743 に答える