問題タブ [database-indexes]

これを行うツールはありますか？SQL クエリを与えると、提案が表示されます。たとえば、次のクエリを最適化しようとしています。

説明

その出力をどのように解釈すればよいでしょうか?

たとえば、次のようなものがあります。

そして後で行う

ActiveRecord やデータベースはインデックスの名前変更も処理しますか? それとも手動でインデックスを削除して再度追加する必要がありますか?

だから、おまけの欄に「Using Where」があるのはいいことだなといつも思っていました。しかし、私は EXPLAIN を解釈する同僚のために茶色のバッグ ランチを計画していましたが、今はよくわかりません。MySQL のドキュメントでは、「Using Where」に関するメモに次のように記載されています。

WHERE 句を使用して、次のテーブルと照合するか、クライアントに送信する行を制限します。テーブルからすべての行をフェッチまたは検査する意図がない限り、Extra 値が Using where ではなく、テーブル結合タイプが ALL または index である場合、クエリに何か問題がある可能性があります。WHERE 句のすべての部分にインデックスを使用している場合でも、列が NULL になる可能性がある場合は where の使用が表示されることがあります。

これにより、WHERE 句にインデックスの一部しか含まれていない場合でも、列に NULL 値が含まれる可能性がある場合でも、MySQL は行を調べると考えるようになります。

本当？もしそうなら、必要がなければ NULL を含まないように列を変更する必要がありますか? スピードブーストは見られますか？

これを行うクエリがあります：

また、parent_id 列に INDEX を設定しました。

クエリで EXPLAIN SELECT チェックを実行すると、次の情報が得られます。

インデックスの where 句にキーが使用されていないようです。ただし、単純なparent_id = 4を実行すると機能します。しかし、parent_id=4 または parent_id=5 を実行すると、同じメッセージが表示されます。

innoDB データベースのテーブル タイプと関係があることがわかりました。その特定のデータベース エンジンで実行される IN 操作がある場合、MySQL はそれを好まないようです。これは EXPLAIN ツールの問題でしょうか、それとも InnoDB に欠けているものでしょうか?

はい、私は知ってDatabaseMetadata.getIndexInfoいますが、それは私が望むことをしていないようです。

A2つのユーザー/スキーマがあります。それらをとと呼びましょうB。

Aと呼ばれるテーブルがありますTAB。ユーザーBがにインデックスを作成しました。A.TABそのインデックスを呼び出しましょうIND。

私が必要とする情報は次のとおりです。TABスキーマのテーブルにあるインデックスA（別名、所有者A）。インデックスの所有者は気にせず、特定のテーブルにあるだけです。

実験してみるとgetIndexInfo、次のことがわかりました。

• 最初の引数catalogは、OracleJDBCドライバーによって完全に無視されているようです。
• 2番目の引数は、返されるテーブル統計とインデックスの所有者をschema制限します
• uniqueそしてapproximate（大まかに）彼らがすべきことをします（与えることapproximate=falseは実際に更新統計ステートメントを実行することを除いて）。

JDBCドライバーが実行するSQLをトレースするとgetIndexInfo(null, "A", "TAB", false, true)、次のようになります。

あなたが両方 を見ることができるように、table_name そして i.ownerあることに制限されていTABます。これは、このクエリがテーブルと同じユーザーが所有するインデックス情報のみを返すことを意味します。

私は3つの可能な回避策を考えることができます：

1. 常に同じスキーマにインデックスとテーブルを作成します（つまり、同じ所有者を持たせます）。残念ながら、それは常にオプションではありません。
2. schemaに設定してクエリを実行しnullます。これは、2つのスキーマに同じテーブル名が含まれるとすぐに醜くなります（特定のスキーマがどのテーブル（つまり、どのテーブル所有者）にあるかを知る方法がないため）。
3. そのSQLを直接実行します（を使用してexecuteQuery()）。どうしてもやむを得ない場合を除いて、このレベルに落ちたくない。

これらの回避策はどれも私には特に喜ばしいものではありませんが、他に何も機能しない場合は、SQLの直接実行にフォールバックする必要があるかもしれません。

データベースとJDBCドライバーの両方が11.2.0.2.0にあります。

つまり、基本的に私の質問は次のとおりです。

1. これはJDBCドライバーのバグですか、それとも私が気付いていないロジックが背後にありますか？
2. Oracleに必要な情報を提供してもらうための、シンプルで合理的に移植可能な方法はありますか？

1. フィールドの一意性制約に対してデータベースインデックスが作成される場合、または複数フィールドの一意性制約に対して複数のインデックスが作成される場合、他のデータベースインデックスとほぼ同じように、オブジェクトをクエリするときに効率を上げるために同じインデックスを使用できますか？使用されている？私の推測では、一意性制約用に作成されたインデックスは効率向上のために作成されたものと同じであり、一意性制約自体は追加のものですが、データベースに精通していません。
2. 長いトランザクションや高い同時実行性などを通じて、複数のフィールドの制約（たとえば、field_aとfield_bが一緒に一意である）を含む一意の制約を破ることは可能ですか？または、一意の制約によって100％の保護が提供されますか。

次のように (Django によって) 生成されるクエリがあります。

134189 エントリを含む GeoLocating テーブルをクエリします。インデックスが追加されると、各クエリの実行に 100 ミリ秒以上かかるため、1 回限りのことには使用できません。応答をキャッシュするので、IP ルックアップは 1 回だけで済みますが、IP ルックアップを大幅に高速化する明らかな方法が欠けているのではないかと考えています。私のテーブル:

次のように両方の列にインデックスを作成します。

次の説明を与えます。

選択を完了するのに 100 ミリ秒以上かかります。

個々のインデックスを 1 つ持つよりもコストがかかります。

これらのリクエストを完了するには、約 100 ミリ秒かかります。

しかし、どちらの方法も時間がかかりすぎます。これについて何かできることはありますか?

私が理解しているように、典型的なデータベーステーブルのインデックスは、より効率的な行ルックアップを提供します。集計関数を使用したクエリをより効率的にするための同様の構造は存在しますか?

例として、多数の行を持つ以下のようなテーブルがあるとしましょう

MAX()各事業所から従業員の給与を効率的に回収したい。この場合、追加の挿入/更新のオーバーヘッドは気にしません。これは、このクエリをかなり頻繁に作成し、テーブルへの書き込みを頻繁に行わないためです。

私のエンジンはMySQLのMyISAMです

アイテムのテーブルがあり、それぞれにa_level、b_level、およびitem_idがあります。すべてのb_levelは1つのa_level専用です（例：b_level14はa_level2の「子」のみです）

何百万ものアイテムがあり、それらすべてが一度挿入されてから、SELECTのみが要求されたとします。

item_idに基づいてアイテムを選択する場合は、item_id列にインデックスを付ける必要があります。これにより、MySQLは数百万のアイテムすべてを表示しますが、これは悪いことです。私はすでにa_levelとb_levelの情報を持っているからです。したがって、特定のレベルに基づいてアイテムを選択し、その列にインデックスがある場合、MySQLは何百万ものアイテムすべてを検索する必要はなく、その特定のレベルのアイテムのみを検索する必要があります。

a_level、b_level（そしてもちろんitem_id）とSELECT WHERE a_level = b_level = item_id =の両方でインデックスを作成する場合、それは悪いことでしょうか？b_levelとitem_idのINDEXとSELECTWHEREb_level = AND item_id =だけで十分/最良の解決策になると思いますか？

それで、私はa_levelとb_level（私が言ったように任意のb_levelは1つのa_levelの「子」です）を持っているので、アイテムを拾うために作成される最も効率的なSELECTとINDEXは何でしょうか？

モデルのフィールドは、foo = models.ForeignKey(Foo)検索を高速化するために、列のデータベースインデックスを自動的に追加します。それは良いことですが、Djangoのドキュメントには、model-metaのフィールドがunique_together同じ扱いを受けるかどうかは記載されていません。にリストされている1つのcharフィールドにunique_together、クイックルックアップのためのインデックスが必要なモデルがあります。フィールド定義に重複を追加しても問題はないことはわかっていますがdb_index=True、興味があります。