問題タブ [database-indexes]

次のクエリがある場合、高速化するためにどのインデックスを作成できますか?

参考までに、このクエリは Rails によって生成されているため、作成方法を完全に制御することはできません。

EXPLAIN を使用すると、次の結果が得られます。

ID = 1

select_type = シンプル

テーブル = 住宅

タイプ = 範囲

possible_keys = index_residentials_on_list_price,index_residentials_on_property_style,index_residentials_on_square_feet,index_residentials_on_modified,index_residentials_on_is_active,index_residentials_on_is_active_and_board_id,index_residentials_is_active_board_id_list_price_property_type,index_residentials_on_is_active_and_created_at_and_modified,dates_and_type,dates_type_price,board_price_type_zip,board_price_type_zip_mls

キー = index_residentials_on_list_price

key_len = 6

参照 = ヌル

行 = 209272

Extra = where の使用

典型的な顧客テーブルがあるとします。

したがって、主キーは Id にクラスター化された一意のインデックスを作成します。

検索を高速化するために、名前フィールドにインデックスを追加したいと考えています。

私の質問は、それらのインデックスに Id を追加する必要があるかどうか、またはそれらのインデックス自体が主キーに関連付けられるかどうかです。

例えば;

……やり過ぎですか？

以下は多かれ少なかれ効率的ですか？

ティア

以下は、DB2 データベースのコマンドを使用して取得できた TCB インデックスです。どう分析したらいいのかわからない。どの列が重要ですか? 彼らはどういう意味ですか？これは一種の初心者の質問であることは知っていますが、助けてください。

TCB インデックス統計:

私は Rails 3.2.3 アプリを使用しており、データベースの移行で外部キーのインデックスを追加しています。ただし、移行を実行した後、キーにインデックスが作成されていないようです。私はmysqlコンソールから直接テストしました。それが私がやったことであり、よりよく説明されています：

次のようなモデルにCar関連するモデルがあります。Owner

それらは既存のDBテーブルだったので、インデックスを追加するために別の移行を作成しました。

その後、移行を実行しましたが、Rails によると、すべてうまくいきました。しかし、mysql にログインして EXPLAIN クエリを実行すると、列に表示されませんowner_index。key

理論的には (そしてこの投稿によると)、前のクエリのキー列は返されるべきowner_indexではなく、返されるべきNULLです。

私は何か間違ったことをした？私は何が欠けていますか？

少し質問があります。プライマリ インデックスとセカンダリ インデックスのパフォーマンスの違いは何ですか? この違いの原因は何ですか？

私はグーグルで調べており、セカンダリ インデックスが別のテーブルに格納されていることがわかったので、これによりすべての操作が遅くなります..しかし、このパフォーマンスの低下を正当化する他の理由がいくつかありますか?

どうもありがとう

delayd_jobは、次のようなクエリを定期的に実行します。

かなり大きなDBマシンのログでは、実行に1/4秒かかると報告されています。選択されているすべての列にいくつかのインデックスをスローすることもできますが、複数列のインデックスからパフォーマンスを向上させることができます。

このクエリに対して作成できる最適な複数列のインデックスは何ですか？これを計算できるツールはありますか？

アップデート

postgresバージョン：9.1.3

1つの既存のインデックス：priority、run_at（「delayed_jobs_priority」という名前）

からexplain analyze：

夜、

3,000 万行近くの大規模でシンプルなテーブルがあります。テーブルには、ほとんどの列のインデックスがあります。更新を実行するのに長い時間がかかります。テーブルへの変更が完了したら、インデックスを削除して再構築することをお勧めしますか?

私が質問する理由は、大きなテーブルでインデックスを再構築できなかった投稿をここで読んだことがあるためです。ただし、このテーブルを 2.2 GB のテキスト ファイルから 20 分でインポートできるため、その理由がわかりません。

テーブルは、いくつかの小さな int と varchar で構成されています。

私が実行した更新クエリは次のようなものでした:

それほど遅くはありませんでしたが、現在、フィールドの 1 つを varchar(4) から varchar(8) に変更していて、非常に長い時間がかかっています。

コマンドライン (Linux) から更新クエリを実行しました。

私はmongoデータベースの分析に取り組んでいます。データを分析するには、先週作成されたすべてのドキュメントを見つける必要があります。現在、データベースには各ドキュメントに関連付けられた作成時間フィールドがあり、mongoのデフォルトのBSON形式で保存されています。コレクションが大きくなるので、同じことを行うには高速な方法が必要です。

データベースはまだ作業中であるため、高速クエリの作成に役立つ場合は、さらに多くのフィールド/インデックスをデータベースに追加できます。

これを行うための最速の方法は何ですか？

クエリでインデックスを使用しようとしましたが、役に立ちませんでした。定義されていますが、使用されていません。

これが私のインデックスです

これは私のクエリ+説明です:

テーブルには 9825 行あり、選択した日付は最新の 9 行でした....したがって、9 行のみをスキャンする必要があります。

何か案は？ありがとう

これを処理する方法については独自の考えがありますが、これについて別の見方があるかどうかを確認したいと思います。これに関する問題は、次のテーブル（サンプルテーブル）があることです

Account テーブルが 500 GB で、AccountSales が 1 TB であるとします。明らかな理由から、これらのテーブルを分割したいと思います。現在のロジックでは、データは日ごとに処理されるため、Account テーブルの日付フィールドで分割することは理にかなっていますが、AccountSales テーブルには日付フィールドがありません。また、データは異なるサーバーから異なる時間にロードされるため、ID と日付に関しては、両方のテーブルのデータは連続していません。同様のアカウントには次のデータがある場合があります

Accounts テーブルについては、CreationDate にクラスター化インデックスを作成し、AccountId を一意の NC インデックスを持つ PK として設定することを考えていました。次に、日付で分割します。

ただし、AccountSales テーブルの処理方法については 100% 確信が持てません。id で処理した場合、Account テーブルと結合すると日付が正しく一致しないため、これを修正する方法がわかりません。

何か案は？これを処理する最善の方法は何ですか? さらに情報が必要な場合は、お知らせください。よろしくお願いします！