20

他の属性の中でも、タイムスタンプ、タイプ、および user_id を持つ MySQL テーブルがあります。
それらはすべて検索および/またはソート可能です。
それぞれにインデックスを作成するか、3 つすべてを含む単一の複合インデックスを作成するか、またはその両方を作成する方がよいでしょうか?

4

2 に答える 2

15

これらのフィールドで個別に検索を実行する場合は、クエリをより高速に実行するために、おそらく個別のインデックスが必要になります。

このようなインデックスがある場合：

mysql> create index my_idx on my_table(tstamp, user_id, type);

そして、クエリは次のとおりです。

mysql> select * from my_table where type = 'A';

そうするとmy_idx、クエリにはそれほど役立ちません。MySQLは、それを解決するために全表スキャンを実行することになります。

于 2010-11-16T14:07:21.257 に答える
10

パブロの答えは正しいですが、複合インデックスが正当化される可能性があることに気付かないかもしれません。

複数のインデックスを持つことができます。持つことは、持つことidx1(tstamp, user_id)からあなたを除外するものではありません...indx2(tstamp, type)idx1reverse(user_id, tstamp)

複合インデックスは、クエリのすべての条件をカバーする場合に最も役立ちます。

SELECT * FROM my_table WHERE tstamp = @ts1 AND user_id = @uid AND type = @type

このようなクエリのパフォーマンスを向上させたい場合は、複合インデックスを追加することを検討できます。

インデックスの欠点は、すべての更新操作が遅くなることです。ただし、ほとんどの一般的なアプリケーションは、更新よりも多くの選択を行い (トランザクション、つまりステートメントの数と、特に影響を受ける/取得されるレコードの両方に関して)、同時に、より遅い更新に対してはるかに寛容です (ユーザーは主に更新の速度を判断します)。システムは、レコードを更新する必要があるときではなく、レコードを取得するのに必要な時間までにシステムを更新します; 再び YMMV と、そのようなルールで再生されないアプリケーションがあります)。

最善の方法は、典型的なワークロードに関してデータベースのパフォーマンスをテストする方法があれば (いくつかの典型的な SQL スクリプトを作成します。独立した反復可能なものにするか、アプリケーション レベルで単体テストを作成します)、データベースを客観的に調整できます。

編集 また、機能面でシステムに影響を与えることなく、インデックスを追加および削除できることを認識してください。したがって、システムを実際に使用しているときに、後でインデックスを調整できます。通常は、低速の SQL クエリを収集してプロファイリングし、インデックスを追加することでメリットが得られる条件を探します。

于 2010-11-16T14:53:37.707 に答える