問題タブ [query-performance]

これらのフィールドを持つテーブルがあります: userid、logintime、birthdate
生年月日 X と Y の間のすべてのユーザーを取得する必要があります。

birtdate だけでインデックスを定義した場合、mysql は filesort を使用して、回避したい結果を並べ替えます (テーブルが大きくなり、クエリが一般的になります)。
ログイン時間はWHERE句にも含まれていないため、インデックス（ログイン時間、生年月日）を定義しても意味がありません（生年月日で結果セットを制限しているだけです）

mysqlのエレガントなソリューションはありますか?

これらのテーブルのフィールドは20未満で、プロパティの行数は約900万行、リストの行数は300万行ですが、これは問題にはなりません。これがデータベースの目的です...

Listing_idsのタイプはNumberです。これまでのところ、プロパティテーブルには実際にはリストを指していないlistingidを持つ行が600万行あるため、Oracleは存在しないリストを探すのに多くの時間を費やしていると推測されます。それも意味がありますか？

クエリに対してExplainPlanを実行し、次の情報を取得しました。

編集：テーブルスキーマ：

oracle統計を更新した後に更新された統計：

統計学

統計を更新した後の新しい実行プラン：

これは私の質問です：

テーブルB（StockEntry）には1つ以上のレコードが含まれる場合がありますが、テーブルA（ItemMaster）にはそのItemIDの行が1つしかないことは間違いありません。

WHERE句のサブクエリを削除すると、1つ以上の行が表示されます。WHERE句のサブクエリでmax（RecordID）を選択すると、クエリが遅くなるように感じます。RecordID、InvoiceDate、ItemIDにインデックスがありますが、それでもMySQLログはこのクエリがうまく機能していないことを示しています。なんらかの理由で列の順序を変更できません。

このクエリを最適化するためのより良い方法はありますか？

私はこのクエリを持っています...これは非常にゆっくりと実行されます（ほぼ1分）：

PRIME テーブルには 18,000 行あり、PrimeId に PK があります。

ATTRGROUP テーブルには 24,000 行あり、PrimeId、col2、RelatedPrimeId、cols 4 ～ 7 に複合 PK があります。RelatedPrimeId には別のインデックスもあります。

クエリは最終的に 8.5k 行を返します。これは、ATTRGROUP テーブルの PrimeId または RelatedPrimeId と一致する PRIME テーブルの PrimeId の個別の値です。

ATTRGROUP の代わりに ATTRADDRESS を使用して、同じクエリを実行しました。ATTRADDRESS は、ATTRGROUP と同じキーとインデックスの構造を持っています。11,000 行しかありませんが、これは確かに小さいですが、その場合、クエリは約 1 秒で実行され、11,000 行が返されます。

だから私の質問はこれです：

構造が同一であるにもかかわらず、あるテーブルで別のテーブルよりもクエリが非常に遅くなるのはどうしてでしょうか。

これまでのところ、SQL 2005 と (同じデータベースを使用してアップグレードされた) SQL 2008 R2 でこれを試しました。私たち 2 人が別々に同じ結果を得て、同じバックアップを 2 台の異なるコンピューターに復元しました。

その他の詳細：

• 括弧内のビットは、遅いクエリでも 1 秒未満で実行されます
• 実行計画に手がかりがある可能性がありますが、私にはわかりません。これはその一部で、疑わしい 3 億 2000 万行の操作があります。

ただし、そのテーブルの実際の行数は 320M ではなく、24k を少し超えています。

OR ではなく UNION を使用するように、クエリの括弧内の部分をリファクタリングすると、次のようになります。

...その後、遅いクエリは 1 秒未満かかります。

これに関する洞察をいただければ幸いです。さらに情報が必要な場合はお知らせください。質問を更新します。ありがとう！

ところで、この例では冗長な結合があることに気付きました。本番環境ではすべてが動的に生成され、括弧内のビットはさまざまな形式になるため、これを簡単に削除することはできません。

編集：

ATTRGROUP のインデックスを再構築しましたが、大きな違いはありません。

編集2：

したがって、一時テーブルを使用する場合：

...再び、元の OUTER JOIN に OR があっても、1 秒もかからずに実行されます。私はこのような一時テーブルが嫌いで、常に敗北を認めているように感じるので、使用するリファクタリングではありませんが、これだけの違いがあるのは興味深いと思いました。

編集3：

統計を更新しても違いはありません。

これまでのすべての提案に感謝します。

それほど複雑ではないクエリがあります。実行に250ms近くかかりますが、これはかなり遅いです。EXPLAINを使用してクエリを分析し、seqスキャンに気づきました。このクエリで使用されるすべての列に適切なインデックスを設定しています。だからここからどこへ行けばいいのかわからない。

これが私が持っているものです：

前述のように、スキーマファイルから取得したインデックスは次のとおりです。

シーケンススキャンがこのクエリを殺すものだと思います。そして、私はそのテーブルにかなり徹底的なインデックスを持っています。だから私は迷子になりました。どんな助けでも大歓迎です。

ありがとう。

HBaseをスタンドアロンモードで実行していますが、JavaAPIを使用してテーブルをクエリするといくつかの問題が発生しました。このテーブルには数百万のエントリがあり（ただし、数十億に増える可能性があります）、次の行キーメトリックがあります。

2つの比較操作フィルターを使用して、時間間隔を表す特定の行範囲をクエリします。

ResultScanner＃next（）メソッドを呼び出すと、フィルターで指定されたキー範囲の最後の行に到達するまで、すべてが正常に機能します。ResultScannerが最後の行を返すまでに最大40秒かかります。これは、行の範囲の上限よりも字句的に小さいものです。

filterList内のフィルターの順序をから変更すると

に

スキャナーが結果を返し始めるまで最大40秒かかりますが、最後の行を返すのにそれ以上の遅延はないので、遅延はCompareOp.LESS-フィルターに起因すると考えました。

この遅延を回避するために私が知っている唯一の方法は、upperRowFilterを省略し、行キーが範囲外にあるかどうかを手動で確認することですが、インターネットの検索で問題が見つからなかったため、何か問題があるはずです。

私もすでにキャッシュでそれを取り除こうとしましたが、返される行数よりも小さいキャッシュサイズを使用しても何も変更されず、返される行数よりも大きいキャッシュサイズを使用すると遅延が返されますまだそこにありますが、結果が返される前にもう一度。

何がそのような行動を引き起こす可能性があるのか​​、あなたは何か考えがありますか？私はそれを間違っているのですか、それとも私が見逃しているものがありますか？

前もって感謝します！

PostgreSQL 7.4 (はいアップグレード)

だから私のWHERE条件で私はこれを持っています

代替構文ですが、コストに変更はありません

文字列の開始によって結果を制限する費用対効果の高い方法を探しています。したがって、文字列が 01、123、5555、44444、または 99 で始まる場合は、それを結果セットに追加します。

何かご意見は？

注: FieldID にはインデックスが付けられます。Explain データを表示してクエリのボトルネックを確認します。上記のコードを追加すると、Sort のコストが大幅に上昇し、データ セット/結果の戻りが遅くなります。

Explain からの出力:

クエリが複雑であるため、さらに多くのコードがありますが、コードの一部を削除すると、並べ替えのコストが大幅に削減されます

更新：がらくた！整数ではなく、文字が変化します(10)

このようにクエリを実行すると、インデックスが使用されます

しかし、これを実行するとインデックスは使用されません

またはこれ

これも

私のインデックスは次のようになります

PostgreSQL 7.4 の実行 (はい、アップグレード中です)

クエリを最適化しているのですが、ステートメントの SELECT または WHERE 句で 3 種類の式のいずれかを使用すると、パフォーマンスが向上するかどうかを知りたいと思っていました。

注: これらのスタイルの制約で実行されるクエリは、約 200,000 レコードを返します

例 データは文字が変化します(10) :0123456789また、インデックスも作成されます

1. (部分文字列)

2. (いいね)

3. (正規表現)

また、WHERE 句で一方を他方よりも使用すると、パフォーマンス上の利点がありますか?

1. (部分文字列)

2. (いいね)

3. (正規表現)

SELECT で 1 つのオプションを使用し、WHERE 句で別のオプションを使用すると、パフォーマンスが向上しますか?

MySQL 全文検索機能を使用する場合は、VARCHAR タイプのフィールドに全文索引を定義します。行は INSERT および UPDATE されるため、mysql はインデックスを最新の状態に保つ必要があります。私の質問は、MySQL が FTS インデックスを再構築するのはいつですか?

• A) インデックスに影響を与える INSERT または UPDATE が発生した直後。
• B) 最近 UPDATE または INSERT の影響を受けたインデックスを必要とする最初の SELECT が実行されるとき。
• C) 他の何か。

不必要な背景情報: 私の経験では、オプション B を考えているようです。これは正しいですか? 全文検索を実行するランダムな低速クエリが突然発生し、一部のクエリが低速で他のクエリがそうでない理由がわからないため、質問します。私の推測では、mysql が FTS インデックスを再構築するのを待っている場合、クエリが遅くなる可能性がありますが、これが mysql の仕組みかどうかはわかりません。ランダムな低速クエリの例 (通常、同じクエリは 1 秒未満で実行されます)。低速ログに低速の UPDATE または INSERT はありません。

Lock_time に注意してください。スローログに他の INSERT または UPDATE が表示されないため、何を待っているのかわかりません。それが、FTS インデックスの再構築を待っている可能性があると推測した理由です。

最近のインタビューSELECTで、MySQL データベースのクエリが非常に遅い理由を尋ねられ、次のように思いつきました。

1. 選択で複数JOINの が実行されている
2. キー フィルター フィールドにインデックスがない (インデックス?)

問題の解決策についても尋ねられ、私は次のように言いました。

1. クエリの重要性が高い場合は、データを非正規化します (これがデータの重複につながることはわかっていますが、 JOINs を回避する別の方法はありますか?)
2. フィルター列にインデックスを追加します。

SQL クエリが非効率になる理由について、他に特徴はありますか? クエリを高速化する方法に関するヒントを純粋に探していることに注意してください。DBサーバーは完璧であると仮定してください:-)