3

アプリケーションのすべてのドキュメントを挿入するためのテーブルを作成しました。これは、DOC_ID、FileSize、Dataの3つのフィールドを持つ単純なテーブル（DOC_DATAと呼びます）です。データはvarbinary（max）です。

次に、他のデータ（「ドキュメントの説明」、「作成者」、「顧客ID」など）を含む多くのテーブル（CUSTOMERS_DOCUMENTS、EMPLOYEES_DOCUMENTSなど）があります。私の場合は、このようなものではありません。とにかく、この例を書くことで、自分自身をよりよく表現することができます。これらのすべてのテーブルには、DOC_DATA.DOC_IDへのFKがあります。

ユーザーが顧客ドキュメントを検索すると、次のようなクエリが実行されます。

select CD.*, DD.FileSize
from DOC_DATA DD
join CUSTOMERS_DOCUMENTS CD ON CD.DOC_ID = DD.DOC_ID

私の質問は、潜在的に巨大なテーブルからフィールドも読み取っているため（DOC_DATAテーブルには多くのGBのデータが含まれる可能性があるため）、このクエリのパフォーマンスが低下するのでしょうか、それとも問題ではないのでしょうか。

別の解決策は、すべてのメインテーブル（CUSTOMER_DOCUMENTS、EMPLOYEES_DOCUMENTS、...）にFIleSizeフィールドを配置することです。もちろん、参加はパフォーマンスに少し影響を与えます。今は、一般的に参加するかどうかを尋ねるのではなく、HUGEフィールドに興味がないときに、HUGEテーブルに参加するかどうかを尋ねています。

注：私は新しいシステムを設計しておらず、レガシーシステムを維持しているため、ここでは一般的に最適な設計については説明しませんが、この場合はどちらが最適なオプションであるかについて説明します。

4

1 に答える 1

2

これらの大きな列が存在するためにクエリのパフォーマンスが低下する理由はわかりません。そのデータを読み取ると、パフォーマンスの問題が発生します。具体的には、データベースエンジンにドキュメントを返す必要があるが、クエリではそうしていません。

内部的には、さまざまなyada（max）データ型について、SQLは16バイト程度のポインター（または参照マーカー、転送レコード、またはそれらが呼び出すもの）を行に格納し、実際のデータは別のページセットに格納されます。したがって、その列を読んでいない場合は、それらのページにアクセスする必要はなく、ディスクI/Oヒットは発生しません。

于 2010-05-26T14:13:45.833 に答える