1

現在、約 7,000 万行の非常に大きなテーブルがあり、毎日数千単位で増加しています。このスキーマは毎日ひっくり返っているため、パーティション分割されたテーブルに移動して ddl を再設計しています。

テーブルは基本的にNOT NULL INTEGERS（いくつかの中型、いくつかのINT、いくつかの小さな）のコレクションであり、7列のセットに対して一意の制約が必要です（テーブルにはより多くの列があります）。これは、挿入ごとに計算するのに非常に高価であり、増加しますインデックスファイルのサイズは、私はそれを取得したことがないので、それをドロップして、何とかmd5/多分単純に値を連結することを好みます...まだわかりません.

問題は、このような大きな一意の番号を保持できる唯一の列タイプが varchar であることです。この PK が実際に優れているかどうか疑問に思っています。また、PRIMARY KEY 'part_key' (site_id,id) があるため、要約すると、パーティションの設計で一意の制約を使用する必要があります...これは新しい問題ではないと確信していますが、私はそうではありませんでした。 2つを比較するベンチマーク/ドキュメントを見つけることができません.この問題を経験した人はいますか? 問題は、私がPKまたは一意のフィールドのハッシュ値だけで取得していない場合、PKが8つのフィールド全体である必要があることです（このテーブルにはおそらく1億行以上あることに注意してください） PS：取得は主に7 列のうち 2 列で実行 ディスク サイズは問題ではありません。

4

2 に答える 2

0

mysqlがパーティションプルーニングを取得するまで、テーブルを非正規化して（gulp）偽のパーティション分割を行うことをお勧めします。最初の値のモジュロ 32 を取り、32 個のテーブルを作成するようなことを行います。

更新:どうやら mysql 5.1.6 以降ではプルーニングがサポートされているようです ( http://dev.mysql.com/doc/refman/5.1/en/partitioning-pruning.html )。そのため、私のより強力なアドバイスは、アップグレードしてから mysql が処理できるようにすることです。場合によっては、7 つの列のいずれかのハッシュ値を使用して、パーティショニングを行います。

于 2009-10-14T19:42:33.417 に答える
0

レコード ルックアップに一致する適切なハッシュを見つけることができれば、各パーティションに一意の制約を適用することはそれほど大したことではありません。パーティション サイズが小さいほど、一意の制約のコストが低くなります。（私が間違っていれば、ここの誰かが私を教えてくれると確信しています）。

私はMySQL 5.0で立ち往生しています。4,000 万行を超えるいくつかのテーブルを手動で分割する必要があります。アプリケーションでハッシュできるドキュメント ID があります: floor(docID/10)%100. これにより、100 個のパーティションが得られ、インデックスのサイズを大幅に抑えることができます。テーブルに対してクエリを実行し、ハッシュで行数を数えました。

select count(docID), floor(docID/10)%100 as partno
from documents 
group by partno

幸いなことに、最初の試行で非常に均等な分布を見つけました。あなた自身の式は異なります。あなたの分布がどのようになるかはわかりません。一意の制約がパーティショニングに耐えられないのではないかと心配していますか?

MySQL のパーティショニングを利用できれば、より強力になり、アプリケーションへの影響が少なくなります。

于 2009-11-05T05:29:52.103 に答える