Google アドワーズなどのトラッキング サイトを運営しています。修正のみ行っております。そのサイトでは、彼らが毎月のテーブルを作成し、そのテーブルを 1 つにマージしているのを見ました。これは、クリックと検索の詳細に関する情報を格納するテーブルと、何千万ものレコードを含むマージされたテーブルに対して行われます。何千万ものレコードを持っているマージされたテーブル。このようなテーブルを使用する利点はありますか?また、クエリの実行に 10 分以上かかっています。
2 に答える
利点は次のとおりです。次の利点が得られない場合は使用しないでください。
ログ テーブルのセットを簡単に管理します。たとえば、異なる月のデータを別々のテーブルに入れ、その一部を myisampack で圧縮してから、MERGE テーブルを作成して 1 つとして使用できます。
より多くの速度を取得します。いくつかの基準に基づいて大きな読み取り専用テーブルを分割し、個々のテーブルを異なるディスクに配置できます。このように構成された MERGE テーブルは、単一の大きなテーブルを使用するよりもはるかに高速になる可能性があります。
より効率的な検索を実行します。探しているものが正確にわかっている場合は、基になるテーブルの 1 つだけを検索して一部のクエリを検索し、他のクエリには MERGE テーブルを使用できます。重複する一連のテーブルを使用する多数の異なる MERGE テーブルを使用することもできます。
より効率的な修理を実行します。単一の大きなテーブルを修復するよりも、MERGE テーブルにマップされている個々の小さなテーブルを修復する方が簡単です。
多くのテーブルを 1 つに即座にマップします。MERGE テーブルは、個々のテーブルのインデックスを使用するため、独自のインデックスを維持する必要はありません。その結果、MERGE テーブル コレクションは非常に高速に作成または再マップされます。(インデックスが作成されなくても、MERGE テーブルを作成するときは、引き続きインデックス定義を指定する必要があります。)
オンデマンドで大きなテーブルを作成するための一連のテーブルがある場合は、代わりにそれらからオンデマンドで MERGE テーブルを作成できます。これははるかに高速で、多くのディスク容量を節約できます。
オペレーティング システムのファイル サイズ制限を超えています。各 MyISAM テーブルはこの制限に拘束されますが、MyISAM テーブルのコレクションは拘束されません。
その単一のテーブルにマップする MERGE テーブルを定義することにより、MyISAM テーブルのエイリアスまたはシノニムを作成できます。これを行うことによるパフォーマンスへの実際の顕著な影響はありません (読み取りごとに間接呼び出しと memcpy() 呼び出しが数回あるだけです)。
詳細については、基本情報のリンク、利点と欠点のリンクを参照してください。
MRG_MYISAM は MyISAM テーブルに対してのみ機能します。これは、それ自体ではテーブルの最初のオプションではありません。通常は InnoDB テーブルを使用します。
MRG_MYISAM エンジンは、MySQL がビューとパーティションをサポートする前に発明されました。レンジ パーティショニング (たとえば、月単位のパーティション) は、おそらくあなたが望むものです。
パーティショニングはクエリに関してユーザーに対して透過的ですが、プルーニングを使用して、クエリに対して選択されたパーティションからのみ読み取り、最適化します。
InnoDB テーブルを使用し、 range partitioningを確認することをお勧めします。MRG_MYISAM と MyISAM はまだ使用されています。彼らはあなたのためにうまくいくかもしれません。MyISAM が非常に多くの問題 (クラッシュ リカバリなし、テーブル レベルのロックなど) をもたらすため、何度も問題外になります。