MySQL 5.0インデックス-ユニークと非ユニーク
MySQLのユニークインデックスと非ユニークインデックスのパフォーマンスの違いは何ですか？
2列のコンボでインデックスを作成し、その組み合わせは一意であるとしましょうが、一意ではないインデックスを作成します。 MySQLが使用するパフォーマンスまたはメモリに大きな影響はありますか？
同じ質問、primary keyとnique indexの違いはありますか？
UNIQUEおよびPRIMARY KEYはconstraintsであり、インデックスではありません。ほとんどのデータベースは、インデックスを使用してこれらの制約を実装していますが。インデックスに加えて制約の追加オーバーヘッドは重要ではありません。特に、意図しない重複が発生した場合（発生していない場合）を追跡して修正するコストをカウントする場合は重要ではありません。
インデックスは通常、高い選択性がある場合により効果的です。これは、行の総数に対する個別の値の数の比率です。
たとえば、社会保障番号の列には、100万の異なる値を持つ100万の行があります。したがって、選択性は1000000/1000000 = 1.0です（まれな歴史的な例外はありますが、SSNは一意であることが意図されています）。
ただし、そのテーブルの別の列「性別」には、100万行を超える2つの異なる値しかありません。 2/1000000 =非常に低い選択性。
UNIQUEまたはPRIMARY KEY制約のあるインデックスは、1.0の選択性を持つことが保証されているため、常にインデックスと同じくらい効果的です。
主キーと一意制約の違いについて質問しました。主に、テーブルごとにプライマリキー制約を1つだけ持つことができます（その制約の定義に複数の列が含まれている場合でも）が、複数の一意の制約を持つことができます。一意制約のある列ではNULLを許可できますが、主キー制約の列ではNULLを許可してはいけません。それ以外の場合、主キーと一意の実装と使用は非常に似ています。
MyISAMを使用するかInnoDBを使用するかについてコメントで尋ねました。 MySQLでは、用語ストレージエンジンを使用します。これら2つのストレージエンジンには微妙な違いがたくさんありますが、主なものは次のとおりです。
- InnoDBはトランザクションをサポートしているため、変更をロールバックするかコミットするかを選択できます。 MyISAMは事実上常に自動コミットされます。
- InnoDBは外部キー制約を強制します。 MyISAMは、外部キー制約を強制したり、保存したりしません。
これらの機能がアプリケーションで必要なものである場合、InnoDBを使用する必要があります。
あなたのコメントに応答するために、それはそれほど単純ではありません。 InnoDBは実際にはかなりの場合MyISAMよりも高速であるため、アプリケーションの選択、更新、同時クエリ、インデックス、バッファ構成などの組み合わせに依存します。
ストレージエンジンの非常に徹底的なパフォーマンス比較については、 http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/ を参照してください。 InnoDBはMyISAMに頻繁に勝つため、一方が他方より速いと言うことは明らかに不可能です。
ほとんどのパフォーマンス関連の質問と同様に、アプリケーションに回答する唯一の方法は、アプリケーションとデータの代表的なサンプルを使用して両方の構成をテストし、結果を測定することです。
たまたまユニークでユニークなインデックスであるユニークでないインデックスについてよくわかりませんが、それほど多くはないでしょう。オプティマイザーは、インデックスのカーディナリティを調べ、それを使用する必要があります（一意のインデックスの場合は、常に行数になります）。
主キーに関する限り、おそらく非常に多くですが、使用するエンジンによって異なります。
InnoDBエンジン（多くの人が使用しています）は、主キーの行を常にクラスター化します。これは、PKが実際の行データと本質的に結合されることを意味します。 PK（または実際に、範囲スキャンなど）で多くのルックアップを行っている場合、これは良いことです。ディスクから多くのブロックを取得する必要がないためです。
非PKユニークインデックスはInnoDBでクラスター化されません。
一方、他のエンジン（特にMyISAM）はPKをクラスター化しないため、主キーは通常の一意のインデックスのようになります。