2012-02-10 5 views
2

私は次のような状況に陥っています。ユーザーが別のユーザーを追跡している場合は、データを保存します。私が触れることができない別のテーブルは、usernameがプライマリキー(不幸にもIDなし...)であるユーザーを格納します。ストアテーブル内のユーザーに従う

実際、あるユーザーが別のユーザーの後に続く場合は、もう一方が最初のユーザーの後にあるということではありません。

今、ユーザー名を表す2つのvarcharに2つのvarchar's (128)UNIQUE INDEXのテーブルを設計しました。

問題は、私は今、いくつかの古いスタイルのシステムを解析する必要があること、である、と私は15%よう終え、私はすでにこのテーブルの上に550Kエントリを持っています。

指数が大きく、その後16メガバイトであり、データだけ14メガバイト

このデータをより良い方法で保存するにはどうすればよいですか?前述のように、ユーザテーブルはユーザ名をプライマリキーとして使用するため、ユーザ名の代わりにIDを使用することはできません。

+0

外挿してみると、4mlの行と200MBのデータで終了します。なぜそれが問題になるのでしょうか?テーブルのサイズを最小限に抑えることを主張する場合は、各ユーザーにIDを追加し、このテーブルのIDをFollowUserテーブルのソースとして使用する中間テーブルを使用できます。それは半分以上のサイズにカットされますが、正直なところ、なぜ気になりますか? –

+0

インデックスのサイズが大きく、データそのものが大きいため、気になります。/ –

+0

おそらく両方のフィールドを主キーとして使用できますか? MySQLはプライマリキーをクラスタ化インデックスとして使用します。私がそれを正しく理解すれば、これは別々のインデックスをすべて削除するでしょう。 –

答えて

0

気付いたように、すべてのカラムに別々のインデックスを作成すると、MySQLはインデックス内のすべてのデータを複製しなければなりません。

別々のunique indexを作成する代わりに、両方のフィールドで構成されるprimary keyを作成することができます。 MySQLはprimary keyclustered indexとして使用して、データベースのサイズを増やさずに一意性制約が満たされていることを確認します。

0

ID> usernameを含む独自のインデックステーブルを作成することを検討することもできます。

IDを使用してフォロワーをマッピングできます。

これにより、すべてのデータを取得する場合に、余分なオーバーヘッドが発生します。

+0

接続テーブルのより大きなインデックスの代わりに、可能なIDと名前のテーブルがあります。 –

+0

それはまさに私が私の答えで言ったことです;-) – RobinUS2

関連する問題