0

MySQLデータベースを設計しています...

  1. UserIDを主キーとして使用するテーブルがいくつかあります。これらのテーブルはすべて、ユーザーごとに1行あるため、同じ速度で増加します。主キー（UserID）を介してアクセスできることを確認すると、それぞれが一意であるため、このキーにインデックスを付ける必要はないと思います。

  2. また、主キーとして増分番号を持ち、UserIDが2番目の列になるテーブルがいくつかあります。これらのテーブルでは、2番目の列にUserIDの複数のインスタンスがあります。（このUserIDにはそれぞれ多くの友達がいて、それぞれが異なる行にリストされています）。これらのテーブルは非常に長くなると思いますが、それほど広くはないため、GBに関しては大きくありません。

質問：上記のパート2（ユーザーID / 2番目の列）のテーブルにインデックスを追加し、クエリが結合にユーザーIDを使用している場合（すべての結合はユーザーIDから外れます）、これは結合がより大きなテーブルにアクセスすることを意味します（上記のパート2） ）インデックス付きのUserIDを介して、したがってこれらの大きなテーブルへのアクセス速度は、パート1の小さなテーブルと同様になりますか？

UserIDを一意の主キー（短いテーブル）またはインデックス付きの列（大きいテーブル）として使用して結合の一部となるすべてのテーブルを持つ-これは、テーブルが取得した場合の良好な応答時間を確保するという点で、妥当な設計のように見えますか？かなり大きい-これまでに1億行になりましたか？（HWなどの他の要件を除く）。

考え？どうも

4

2 に答える 2

2

主キーフィールドは自動的に一意のインデックスの一部になるため、その上にさらに別のインデックスを追加する必要はありません。

、、、および/または句whereで使用されるフィールドにインデックスを付けることは、経験則として適切です。joinorder by

速度的には、インデックスを追加（または削除）することでパフォーマンスが向上するかどうかは誰にもわかりません。シンプル/スモールDBの場合、インデックスは常に主要なスピードアップです。大規模で複雑なスキーマの場合、一部のシナリオでは実際にパフォーマンスが低下する可能性があります。確認するには、システムのベンチマークを行う必要があります。しかし、一般的に、インデックス=良いです。

于 2013-01-02T20:49:08.027 に答える
1

列がテーブルの主キーとして定義されている（または列のセットが定義されている）場合、それに関連付けられたインデックスがあります（それら）。主キーに関するMySQLリファレンスを参照してください。

sを持つクエリを実装している場合はJOIN、Marc Bがすでに述べたように、結合する列（この場合はuserId）にインデックスを追加することをお勧めします。

クエリが結合にUserIDを使用している場合（すべての結合はUserIDから外れます）、これは、結合がインデックス付きのUserIDを介してより大きなテーブル（上記のパート2）にアクセスすることを意味します

ただし、あなたが尋ねたように、MySQLがあなたが作成したインデックスを使用するかどうかは定かではありません。クエリの構造と結果のセットに含まれる可能性のあるデータによっては、 MySQLクエリオプティマイザが追加したインデックスを使用しないことを決定する場合があります。MySQLがインデックスを使用しているかどうかを確認する方法は、EXPLAINクエリを実行することです。その構文と、それを使用してクエリを最適化する方法を参照してください。特定のインデックスを使用するようにクエリオプティマイザをガイドできますこれにより、クエリプラン分析とクエリ実行パフォーマンスの両方の時間を節約できる可能性がありますが、いくつかのテストを実行して、適用したインデックスが本当に優れていることを確認することをお勧めします。また、テーブル内のデータが大きくなると、クエリのパフォーマンスが低下する可能性があるため、クエリのパフォーマンスを定期的にチェックして、インデックスを配置する必要があることにも注意してください。

クエリの2番目のテーブルが常にuserIdフィールドでクエリされる場合は、MySQL5.1以降で提供されているパーティショニングサポートを活用することをお勧めします。メインテーブルのシャードレコードをバックグラウンドでいくつかのテーブルに分割し、そのルールに従えば、クエリのパフォーマンスを大幅に向上させることができます。

于 2013-01-02T21:26:29.940 に答える