数百万の行を持つ 2 つの同一のテーブルが必要であり、それらにビジネス トランザクションがあり、両方のテーブルにまったく同じ情報があるとします。1 つの列は、行が「販売」か「注文」かを指定し、他の列は名前 (通常は繰り返されます)、日付、金額、税金などを指定します。
テーブル内のデータは整理されていないため、当然のことながら、Sales と Orders およびその他のデータはまったく並べ替えられません。
唯一の違いは、テーブルの 1 つに、一意の主キーを持つ追加の列があることです。
主キーを含まない同じ WHERE 句を使用して同じクエリでテーブルをクエリした場合。WHERE action = "sale" and name = "Bob Smith" のようなクエリが含まれる可能性があります。
それらの1つは、havix an indexの場合、他のものよりも高速になりますか??
すべてのインデックスは、次のような純粋な冗長性です。
クエリでインデックスを利用できる場合、通常、高速化は上記の要因を大幅に上回ります。逆に、インデックスが使用されていない場合は存在しないはずです。
ただし、インデックスとその上のキーを削除しようとする前に、データが間違っていてもパフォーマンスは問題にならないことを覚えておいてください。少なくとも主キーを持たないテーブルは、アプリケーションのバグ1により重複する行に対して広く開かれており、FOREIGN KEY の親エンドポイントとして機能できず、その行はクライアント コードで合理的に識別できません。
データにすでに「埋め込まれている」自然の主キーを特定するか、少なくとも代理キーを作成してください (テーブルの 1 つで行ったように)。
1厳密に言えば、このようなテーブルは関係を表すものではなく、もはや「リレーショナル」データベースではありません。関係の数学的概念は集合であり、集合ではありません。つまり、要素が集合に含まれているか含まれていないかのいずれかですが、集合に複数回含まれることはできません。
インデックスを持たない列の条件でクエリを実行する場合、理論的には、PK の有無に関係なく、ほぼ同じパフォーマンスが得られるはずです。ただし、実際には、RDMS の実装に依存します。私の経験から、SQLServerではヒープテーブル（クラスター化されたキーのないテーブル）をクエリすると全体的なパフォーマンスが低下することが確実にわかりますが、Oracleはヒープをはるかにうまく処理し、同じパフォーマンスを期待できます.
インデックス付きテーブルには、ディスク上のスペースを占有する追加のフィールドがあります。
クエリの説明は、2 つの方法のいずれかで満たすことができます。where句の列のテーブルにインデックスがないと仮定します。その場合、クエリは全テーブル スキャンを実行します。その場合、主キーの追加スペースが問題になります。各レコードは、たとえば、そのレコードの方が他のレコードよりも 4 バイト長くなります。通常、これにより、読み取る必要のあるテーブルの数が増え、クエリの時間が長くなります。
各ベース レコードが 100 バイトの場合、主キーを含む各レコードは 104 バイトになり、クエリ全体が約 4% 長くなると推測できます (他の要因が働いていますが、これにより大まかなアイデアが得られます。起こります）。
一方、where句を満たすインデックスが存在し、結果セットが全体のデータよりもはるかに小さい場合、エンジンはインデックス内の値を検索し、適切なページを見つけて、ページから結果をフェッチします。この場合、フェッチごとに約 1 ページが読み取られるため、2 つのパフォーマンスは似ているはずです。
そうは言っても、テーブルには一意の自動インクリメント主キーが必要であるという考えを強く支持します。
クエリの Where 部分に使用しているフィールドでテーブルがインデックス付けされている場合、インデックス付けされたテーブルははるかに高速になります。
Mysql リファレンスでは、ここで説明しています。