0

dateTimeのdayとIntegerのuser_idという名前の 2 つの列を持つテーブル/スキーマがあります。両方の列にインデックスを作成したことを知っています。

インデックスによって使用される追加スペースの大部分と 2 つの列しかないことを考えると、インデックス作成によって得られるパフォーマンスの向上はそれだけの価値があるでしょうか? それらをどのように正当化しますか？

MongoDB または MySQL を使用する場合、これはどのように異なりますか?

4

2 に答える 2

2

行数が少ない場合、インデックスによる大幅な改善は見られない可能性があります。行数が多い場合は、大幅な改善が見られるでしょう。

良いことは、推測する必要がないことです。また、実際には少数と多数が何を意味するのかについて悩む必要もありません。最新のすべての SQL dbms には、SELECT ステートメントのパフォーマンスを測定する何らかの方法が含まれています。これには MySQL が含まれます。

于 2012-10-25T18:02:31.353 に答える
1

インデックス作成によって得られるパフォーマンスの向上はそれだけの価値がありますか

実行するクエリによって異なります。

  • 次のようなものがある場合:の場合、先頭にが含まWHERE day = ...れるインデックスが必要になります。インデックスを適切に使用すると、特に大規模なデータ セットの場合、クエリを何桁も高速化できます。day
  • OTOH、すべての追加のインデックスは、スペース/キャッシュと INSERT/UPDATE/DELETE のパフォーマンスにコストがかかります。

結局のところ、現実的な量のデータを測定して、独自の結論を出すことをお勧めします。

ところで、InnoDB を使用している場合、テーブルはクラスター化され( InnoDB クラスター化インデックスについても参照)、テーブル全体が実質的にプライマリ インデックスに格納されます。クラスター化されたテーブルのセカンダリ インデックスには、PK フィールドのコピーが含まれていますuser_id。また、テーブルには 2 つのフィールドしかないため、{ day} のセカンダリ インデックスも同様にカバーuser_idされ、クラスター化されたテーブルで発生する可能性がある二重ルックアップを回避します。事実上、2 つの別個の (ただし同期された) B ツリーと、どちらにアクセスしてもインデックスのみのスキャンになります (これは良いことです)。もちろん、単に { の代わりに{ day, } に複合インデックスを明示的に作成することもできます。user_idday}、非常によく似た効果があります。

于 2012-10-26T13:41:45.580 に答える