私は次のような状況に陥っています。ユーザーが別のユーザーを追跡している場合は、データを保存します。私が触れることができない別のテーブルは、username
がプライマリキー(不幸にもIDなし...)であるユーザーを格納します。ストアテーブル内のユーザーに従う
実際、あるユーザーが別のユーザーの後に続く場合は、もう一方が最初のユーザーの後にあるということではありません。
今、ユーザー名を表す2つのvarcharに2つのvarchar's (128)
とUNIQUE INDEX
のテーブルを設計しました。
問題は、私は今、いくつかの古いスタイルのシステムを解析する必要があること、である、と私は15%よう終え、私はすでにこのテーブルの上に550Kエントリを持っています。
指数が大きく、その後16メガバイトであり、データだけ14メガバイト。
このデータをより良い方法で保存するにはどうすればよいですか?前述のように、ユーザテーブルはユーザ名をプライマリキーとして使用するため、ユーザ名の代わりにIDを使用することはできません。
外挿してみると、4mlの行と200MBのデータで終了します。なぜそれが問題になるのでしょうか?テーブルのサイズを最小限に抑えることを主張する場合は、各ユーザーにIDを追加し、このテーブルのIDをFollowUserテーブルのソースとして使用する中間テーブルを使用できます。それは半分以上のサイズにカットされますが、正直なところ、なぜ気になりますか? –
インデックスのサイズが大きく、データそのものが大きいため、気になります。/ –
おそらく両方のフィールドを主キーとして使用できますか? MySQLはプライマリキーをクラスタ化インデックスとして使用します。私がそれを正しく理解すれば、これは別々のインデックスをすべて削除するでしょう。 –