2つのフィールドをカバーするテーブルに一意のインデックスがある場合、各フィールドに別のインデックスを追加する必要がありますか？

例：

私のテーブルは次のようになります。

usersID次に、との両方をカバーする一意のインデックスを追加しますuserTypesID。

さらに2つのインデックスを追加する価値はありますusersIDかuserTypesID？例えば：

これらの追加のインデックスを追加すると、一部のクエリが高速化されますか？そのような：

または

私はInnoDBでMySQLを使用しています。

セマンティクスの観点から主キーは必要ないので、主キー（または一意のインデックス）を使用すると、一意でないインデックスよりもクエリが高速になりますか？

インデックスに適しているが一意ではない2つの列があります。ただし、2つの列の組み合わせは常に一意です。列もnullではありません。

2つの一意でない列をインデックスとして設定するだけでよいのでしょうか、それとも2つの列の組み合わせに対して主キーを作成するのでしょうか。

アクセスパターンは通常、最初の列が指定された値である2つまたは4つの行を変更します（そして、すべての組み合わせが一意であると述べたように、2番目の列は異なります）。

たとえば、col1とcol2は次のようになります

1 1
1 2
1 3
1 5
2 1
2 2
2 3
2 5
3 1
3 2
3 3

例として、行（1、2）と（1、3）を一度に変更します。

フォローアップの質問はデータ型についてです。col1はsmallintに適合し、col2はtinyintに適合します。ただし、単一のインデックスに結合する場合、intよりも小さい型や異なる型を使用した場合のパフォーマンスへの影響はわかりません。マニュアルには、主キーに使用すると複数の列が連結されると記載されています。同じタイプのsmallintを使用する方が良いですか？またはintを使用しますか？メモリアクセスに関しては、整列されていません、フルワードアクセスが最速ですか？これはここに影響を及ぼしますか？

現在、特定のSQLクエリに必要なため、インデックスを作成しています。しかし、それらは互いに重なり始めています。

それらを効果的に定義する規則はありますか？

例えば：

• column1 と column2 に 2 つのインデックスがある場合、column1、column2 による複合インデックスは両方の列による選択を改善しますか?
• column1 と column2 によるインデックスと、column2 と column1 によるインデックスとの違いは何ですか?

こんにちは、データベースを最適化する方法について、1 年もかからないように助けてもらいたいと思っていました。高速化するにはインデックスを追加する必要があることはわかっていますが、何に追加すればよいか正確にはわかりません。

私のデータベースの3つのテーブルは次のとおりです。

テーブル tourPattern2 には約 33000 行が含まれ、journeyPatternTimingLink2 には約 1300 万行が含まれ、回線とサービスは約 70000 行含まれています。

最適化しようとしているクエリは次のとおりです

これまでこのサイズのテーブルを実際に扱ったことがないので、そもそも正しく結合しているかどうかわかりません。phpmyadmin からのクエリで EXPLAIN を実行しているスクリーンショットもアップロードしましたが、結果を解釈する方法が正確にはわからないので、助けていただければ幸いです。

ご協力いただきありがとうございます。

複数の列でインデックスを使用する方法

元のインデックスには にインデックスがありますがblock_id、2 列の一意のインデックスに既にある場合は必要ですか?

複数の列を持つインデックス

(a,b,c)

• a、b、c を検索できます
• a と b を検索できます
• を検索できます
• a と c は検索できません

これは一意のインデックスにも適用されますか?

テーブル

インデックスの起源

インデックスの代替

最近、Oracle データベースを新しい環境にエクスポートしました。残念ながら、インデックスの多くは作成できませんでした。これらのさまざまなSQLを生成する方法があるかどうか知りたいです。

たとえば、テーブルを選択して上部のリストの [SQL] タブをクリックすると、SQL 出力が自動的に生成されることを私は知っています。(スクリーンショットを参照) ただし、すべてではないにしてもほとんどのデータベースに対してこれを行う必要があります。それは私が最も興味を持っているインデックスです。

http://i.imgur.com/dpcsE.jpg

私は2200万のレコードを持つ大きなテーブルを持っています。次のクエリを実行したい：

パフォーマンスを向上させるために、endDataフィールドにBTREEインデックスを追加しました。

クエリ実行プランの分析を開始した後：

今から15〜7日前のパラメータを取得したい場合：

次の実行プランで2,762,088行を処理しました。

間隔を1日増やすと、次のようになります。

EXPLAINによると、MySQLは22,923,126行すべてを処理する予定です。

たとえば、WHEREプロセス22,925,642で条件なしで選択します。

実行計画を改善してもいいですか？たぶん私はどこかで間違いを犯しているのでしょうか、それとも通常のMySQLの振る舞いですか？

MYSQL データベースに多数のインデックスが作成されたテーブルがありますが、これらのインデックスのどれが役に立ち、どれが役に立たないかわかりません。本番環境で使用されているインデックスを知りたいです。

インデックスのログを使用する方法はありますか?

EXPLAIN コマンドは知っていますが、これは 1 つの特定のクエリに対するものです。複雑なシステムを使用しているため、使用されているクエリが何であるかを正確に知ることができません。一般的なログを回して、すべてのクエリを取得し、それらすべての EXPLAIN を作成してから、集計結果を取得することもできますが、これを行うにはもっと簡単な方法が必要です。

この論文でリーマンとヤオが提案したデータ構造（B^リンクツリー）とアルゴリズムに基づいてデータベースインデックスを実装しようとしています。2ページで、著者は次のように述べています。

ディスクは固定サイズのセクションに分割されています（物理ページ。このペーパーでは、これらはツリーのノードに対応します）。これらは、プロセスによって読み取りまたは書き込みができる唯一のユニットです。[強調鉱山]（...）

（...）プロセスはディスクページをロックおよびロック解除できます。このロックは、そのプロセスにそのページに対する排他的な変更権限を与えます。また、プロセスでページを変更するには、そのページをロックする必要があります。（...）ロック は、他のプロセスがロックされたページを読み取ることを妨げません。[強調鉱山]

私の解釈が正しいかどうかは完全にはわかりませんが（学術論文を読むことに慣れていません）、強調された文章から、著者はページを読み書きする操作が「アトミック」であると想定されていることを意味していると結論付けることができると思います、プロセスAがすでにページの読み取り（または書き込み）を開始している場合、別のプロセスBは、Aが読み取り（または書き込み）操作の実行を完了するまで、同じページの書き込み（または読み取り）を開始できないという意味です。 。もちろん、同じページを同時に読み取る複数のプロセスは、排他的に異なるページで任意の操作を同時に実行する複数のプロセス（PページのプロセスA、QページのプロセスB、RページのプロセスCなど）と同様に、正当な条件です。 ）。

1. 私の解釈は正しいですか？

2. POSIXread()とwrite()システムコールが上記の意味で「アトミック」であると想定できますか？ファイル記述子の位置と読み取りまたは書き込みされるチャンクの指定されたサイズに基づいて、特定の呼び出しread()または呼び出しを一時的にブロックする必要があるかどうかを判断するために、内部ロジックを持つこれらのシステムコールに依存できますか？write()

3. 上記の質問に対する答えが「いいえ」の場合、自分のロック機構をどのように回転させる必要がありますか？

text[]（配列）列が定義されたPostgreSQLデータベーステーブルがあります。これらの列を使用して、データベース内の特定のレコードを次のように検索しています。

私が抱えている問題は、約100万件のレコードがあると、クエリが非常に遅くなることです。私の質問は単純ですが、配列列にはさまざまな種類のインデックスがありますか？この場合に作成するのに最適なインデックスのタイプを知っている人はいますか？（さまざまなタイプがあると仮定します）。

念のため、これがexplain analyze応答です。

前もって感謝します！