問題タブ [query-optimization]

データベースに 7k 以上のレコードを持つテーブルがあります。そのテーブルで特定の ID を検索するクエリがあります (ID は自動インクリメントされます)。

クエリは次のようになります->

このクエリは、その 7k + データに対してすべての検索を行います.......とにかく、このクエリを最適化して、検索が 500 または 1000 レコードでのみ行われるようにする方法はありませんか....これらのレコードが増加するにつれて日ごとに、私のクエリはますます重くなります。何か提案はありますか?????

ルート用と空港用の 2 つのテーブルがあります。

Routes には 9000 を超える行が含まれており、すべての列にインデックスを付けました。空港はわずか 2000 行で、すべての列にインデックスを付けました。

このクエリを実行すると、300 行を返すのに最大 35 秒かかる場合があります。

「DESCRIBE」で実行すると、次の情報が得られますが、それが何を言っているのか100％確信が持てません。

私が考えることができる唯一の代替手段は、2 つの個別のクエリを実行し、それらを PHP で結合することですが、このようなものが mysql サーバーを停止させる可能性があるとは信じられません。いつものように、私は何か愚かなことをしていると思います。SQL は私の最大の弱点です。

私はmysqlにかなり慣れており、クエリをクリーンアップするためのヒントが必要です。サイト全体でいくつかのバリエーションで使用されます。いくつかのサブクエリから派生したテーブルがあり、楽しいことが起こっています。クエリは次のとおりです。

ここに説明があります：

そしてテーブル：

一連のスパース ベクトルを格納するテーブルがあるとします。スパース ベクトルとは、ゼロ以外の値のみを明示的にデータ構造に格納することを意味します。100 万次元のベクトルを持つこともできますが、ゼロ以外の次元の値のみを保存します。したがって、サイズはベクトルの次元ではなく、ゼロ以外のエントリの数に比例します。

テーブル定義は次のようになります: vector_id : int ディメンション : int 値 : float

現在、通常のプログラミングの世界では、2 つのベクトルの内積または内積を O(|v1| + |v2|) 時間で計算できます。基本的に、アルゴリズムは、次元ごとに並べ替えられたスパース ベクトルを格納し、次元間の衝突が見つかるまでそれぞれの次元を反復処理し、共有次元の値を乗算し、いずれかのベクトルの最後に到達するまでそれらを加算し続けることです。 .

SQLでこれを実現する最速の方法は何ですか?

私は 2 つのテーブルを持っています。1 つ目は大きなテーブル (数百万行) で、最も興味深い列は "キー" と呼ぶ整数です。ただし、このソリューションは、日付または日時の範囲でも同じであると思います。

2 番目のテーブルははるかに小さく (数千行)、キーの範囲で定義された興味深い属性が多数含まれています。次の構造があります。

key_lower_bound : int key_upper_bound : int Interesting_value1 : float Interest_value2 : int Interest_value3 : varchar(50) ...

最初のテーブルのすべての値を検索し、最初のテーブルのキーが間隔 [key_lower_bound, key_upper_bound) 内にあるかどうかに基づいて、それらを 2 番目のテーブルと「結合」したいと考えています。

これは、数学的にはスパース内積またはスパース ドット積のようなものですが、これらの範囲が 2 番目のテーブルに含まれているため、少し奇妙です。それでも、これをコードで書くとしたら、O(|最初のテーブル| + |2番目のテーブル|) アルゴリズムになります。最初のテーブルの各キーが 2 番目のテーブルの範囲に属しているかどうかを判断するために、両方の (並べ替えられた) リストへのポインターを保持し、それぞれを調べます。秘訣は、両方のリストがソートされているため、最初のテーブルのキーを調べるたびに 2 番目のリストを反復処理しないことです。

最も明白な SQL クエリ (キーが > key_lower_bound および < key_upper_bound であることを確認することを含む) を作成すると、非常に時間がかかります。

実際には、2番目のテーブルがkey_lower_boundsでソートされている場合、クエリエンジンは2番目のテーブルの各行に対して各比較を行っていると思うため、その単純なクエリで何らかの二次的な動作が行われている必要はありません。したがって、目的の O(|first table| + |second table|) の動作ではなく、O(|first table| x |second table|) のような動作を取得しています。

これを行うために線形 SQL クエリを取得することは可能ですか?

JOIN クエリは複数のクエリよりも高速ですか? (メイン クエリを実行し、メイン クエリの結果に基づいて他の多くの SELECT を実行します)

それらを結合すると、アプリケーションの設計が非常に複雑になるため、私は尋ねています

それらがより高速である場合、誰かがどれだけ大まかに概算できますか? 1.5倍なら気にしないけど、10倍なら気にするかな。

OracleSTART WITH ... CONNECT BY句は、同じクエリで条件を適用する前に適用されます。WHEREしたがって、WHERE 制約は最適化には役立ちませんCONNECT BY。

たとえば、次のクエリはおそらく全テーブル スキャンを実行します ( の選択性を無視しますdept_id)。

私は2つの方法でパフォーマンスを改善しようとしました:

クエリ A:

クエリ B:

どちらのクエリも元のクエリよりもはるかに優れたパフォーマンスを発揮しましたが、Oracle 10g リリース 2 では、クエリ B が A よりもはるかに優れたパフォーマンスを発揮しました。

CONNECT BYandWHERE句に関して同様のパフォーマンス最適化を行いましたか? クエリ B がクエリ A よりもはるかに優れていることをどのように説明しますか?

次のデータベース テーブルを検討してください。

• 13,000,000 行 (メッセージごとに 1 行) のテーブル「メッセージ」。
• 3,000,000 行 (ユーザーごとに 1 行) のテーブル "users"。

次のクエリは、一連のメッセージと対応するユーザーを取得するために使用されます。

各クエリで 100 件のメッセージがフェッチされます。

「メッセージ」は、id (主キー、自動生成されないBIGINT ) および user_id でインデックス化されます。

「users」は id でインデックス化されます (主キー、INT 自動生成)。

データベースは MyISAM を使用した MySQL です。

現在、「メッセージ」は「id」でインデックス化されているため、クエリの実行には3000ミリ秒以上かかるため、正しい行を取得するのは非常に迅速です。

私の質問は次のとおりです:記述シナリオとセットアップを考えると、3000ミリ秒のクエリ時間は「正常」ですか、それとも何か不足していますか? さらに詳細が必要な場合はお知らせください。

更新 #1:テーブルの定義は次のとおりです。

定義で私が観察した唯一の「非標準」のことは、「messages.id」がINTではなくBIGINTであることです。それがヒントになりませんか？

テーブルには2つの列があります。

私はテーブルに4つのアイテムを置きました：

今私がする場合：

私は恐ろしい「ファイルソートを使用して」取得します。どうしたの？このページによると、注文にはインデックスを使用する必要があります。私は何か間違ったことをしていますか？

XPではMySQL5.0.41で、ubuntuでは5.0.67でテストされています。

更新：テーブルに1,110,000行を追加し、VARCHAR列を追加してテキストで埋めました。テーブルサイズは135MBになりましたが、まだ「ファイルソートを使用」しています。

1. たくさんの行をすばやく追加する方法について、誰かがヒントを持っていますか？
2. クエリ最適化テストに「十分な大きさ」のテーブルをどの時点で検討する必要がありますか？

いくつかのかなり大きなテーブル（最大のテーブルは10 mil。レコード）で5つの結合を持つクエリを取得しましたが、行が存在するかどうかを知りたいです。これまで、行が存在するかどうかを確認するためにこれを実行しました。

このクエリを使用すると、ストアドプロシージャで22秒かかり、「インスタント」に近づけたいと思います。これも可能ですか？それをスピードアップするために私は何ができますか？

参加しているフィールドとWHERE句のフィールドのインデックスを取得しました。

何か案は？