MRGテーブルには、いくつかの小さなテーブルにまたがる1B +行が含まれています。追加の観測値がMRGテーブルに追加され、MRGテーブルが最後のテーブルに追加されます。MyIsam MRG - 一意性を管理するベストプラクティス
何らかの理由で、同じプライマリキーを共有する2つの重複した行があるようです。私はこれがMRGテーブルの限界であることを知っており、私たちのケースでは本当に問題ではありません(単に無駄な冗長性を意味する)。重複は、システムクラッシュの後に挿入されたと考えられます。つまり、アーカイブに挿入する前に一時テーブルから重複を削除するアプリケーションのコードによって、再処理が適切に処理されませんでした。
これはあまりにも多くの処理時間を必要としない一意性を維持するためのベストプラクティスのセットですか?
あなたの質問が多くの牽引力を得るかどうかは疑問です。私はMRGを15年前に使いました。それ以来、MRGを使っている人は誰も聞いていません。 MyISAMは遠ざかり、MRGはそれを使用しています。 'PARTITIONing'は主にそれを置き換えるものです。しかしそれはほとんど役に立たない。なぜあなたは1つの巨大なテーブルの代わりにMRGを使用していますか? –
1日に数百万の行が更新されます。小さいテーブルのコレクションを使用すると、並列化が可能になります。はるかに高速かつコンパクトなバックアップが可能なので、myIsamに固執する。しかし、確かに、あまりにも遠い未来において、分割されたinnodbに切り替える可能性が最も高い。その一方で、一意性を強制するプライマリキーを持つ統一テーブルを使用します。理想的ではありませんが、仕事をします – user3127882
MyISAMはPARTITIONingを処理するため、一意性チェックが行われます。 –