0

こんにちは、スタックオーバーフロー...

私の組織では、内部プロセスの処理に SugarCRM を使用しています。私たちは約を輸入しています。選択したテーブルへの 27Gig 相当の MsSQL データ。私がaccounts_contactsと呼ばれるテーブルの1つに沿って作業していたので、「アカウント」を「連絡先」にリンクする中間テーブルです(驚き)。テーブル構造は次のとおりです。

名前 タイプ 照合順序 Null デフォルト id varchar(36) utf8_general_ci いいえ なし
contact_id varchar(36) utf8_general_ci はい NULL
account_id varchar(36) utf8_general_ci はい NULL
date_modified datetime はい NULL
削除された tinyint(1) はい 0

デモデータ:

0001391a-9d28-4bd0-9cec-f469cd244ca7 19135ac7-d47c-e111-b389-1cc1dee8bacd 1a135ac7-d47c-e111-b389-1cc1dee8bacd 0000-00-00 00:00:00 0

000262b6-a0ef-48de-b0f6-47db097b35d6 43080e24-a24d-e111-8cf6-1cc1dee8aa73 44080e24-a24d-e111-8cf6-1cc1dee8aa73 0000-00-00 00:00:00 0

00042aa7-39cd-4fcb-9f47-dc2b31c69a11 e9764a4d-d921-e111-8e18-1cc1dee8bacd ea764a4d-d921-e111-8e18-1cc1dee8bacd 0000-00-00 00:00:00

現時点では、上記のテーブルは約です。55k 行。

私の質問: 速度とパフォーマンスのために、このテーブルが contact_id と account_id のインデックスを保証するのはどの時点でしょうか?

4

1 に答える 1

1

contact_id と account_id のインデックスを組み合わせると、アカウントと連絡先を結合する際のパフォーマンスがすぐに向上します。テーブルにインデックスを追加しない唯一の理由は、テーブル データの挿入/更新時にインデックスの同期を維持するオーバーヘッドです。したがって、そのリンク テーブルへの書き込みが多い場合は、インデックスへの影響をベンチマークする必要があります。それ以外の場合、ほとんどそのテーブルから読み取るだけの場合は、インデックスを作成します。

于 2012-08-31T13:25:42.753 に答える