同じ列に一意の通常のインデックスを設定するのはどのくらい間違っていますか?
-
08-07-2019 - |
質問
次のテーブル構造を持っています
CREATE TABLE `table` (
`id` int(11) NOT NULL auto_increment,
`date_expired` datetime NOT NULL,
`user_id` int(11) NOT NULL,
`foreign_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `date_expired` (`date_expired`,`user_id`,`foreign_id`),
KEY `user_id` (`user_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
お気づきのとおり、user_idに重複したインデックスがあります: date_expired
& user_id
。データが一意であることを確認したいので、もちろん一意のインデックスが必要です。
インデックスが重複する理由は、 user_id
インデックスがない場合、メインの検索クエリに4秒かかるためです。追加のインデックスを使用すると、1秒かかります。クエリは user_id
のテーブルに参加し、 date_expired
をチェックしています。
テーブルには275レコードしかありません。
- 同じフィールドに一意の通常のインデックスを作成するのはどれほど悪いですか?
- テーブルが純粋にidである場合、データよりも大きいインデックスを持つのはどれほど悪いですか?
解決
( user_id
、 date_expired
、 foreign_id
)として一意のインデックスを作成した場合、同じ利点が得られると思います user_id
の通常のインデックスと一意のインデックスのみ。 MySQLは、インデックスの最初の列を使用して、 user_id
のインデックスと同じ方法で、結合の行数を削減できます。
詳細については、 MySQLのインデックスドキュメントを参照してください。情報。
スペースを節約するために、スキーマの他の場所で id
auto_increment列を参照していますか?一意のインデックスはテーブル内の他のすべての列をカバーするため、本質的にプライマリキーそのものであり、そうでない場合は削除できます。
EXPLAINをプレフィックスとして付けることで、クエリが使用しているキーを確認できます。
他のヒント
重複したインデックスが何を意味するのか理解できません。テーブルには3つのインデックスがあります:
- 主キー 'id'に1つ(一意であることを意味します)
- 「date_expired」、「user_id」、および「foreign_id」の組み合わせ用の別の一意のもの
- 3番目の「user_id」のみ
重複がないため、異なる処理を行う3つの異なるインデックスがあります。表示されているuser_idに関連するクエリを高速化するには、3番が必要です。したがって、この特定のテーブルに問題はありません。何も複製していません。 2番目の質問に関しては、ニーズに依存しますが、データよりもインデックスで多くのスペースを使い果たすことは確かに悪いことではありません。
たとえば、1つのインデックスに他のインデックスが含まれているため、UNIQUE( 'user_id')とKEY( 'user_id')(MySQLで許可されるかどうかもわかりません)が必要です得るものは何もありません。
1つのフィールドを含む複数のインデックスを保持することは、まったく悪くありません(基本的に、異なるインデックスを作成します)。書き込みのパフォーマンスにはわずかな影響がありますが、それはすべてのインデックスが最初にある場合の典型的なトレードオフです。 インデックスがデータ自体よりも多くのスペースを消費していても、スペースが安価であれば悪くありません。あなたの場合、エントリ数が非常に少ないという事実を考えると、安いはずです。
あなたの立場で私が尋ねる質問は次のとおりです。このような小さなテーブルのインデックスは、クエリの実行時間にどのように深刻な影響を与えますか?たぶん、あなたは何か間違ったことをしているのでしょう(このテーブルに対する冗長なクエリの多くについて考えています)。