問題タブ [sql-tuning]

マニュアルのこのページによると、 indexes don't need to be maintained. ただし、継続率が の PostgresQL テーブルで実行しており、時間の経過 (数日) に伴い、クエリの大幅な低下が見られますupdates。インデックスを削除して再作成すると、クエリのパフォーマンスが回復します。deletesinserts

すぐに使用できる設定を使用しています。
このテストのテーブルは、現在、空の状態で開始され、50 万行にまで増加しています。かなり大きな行 (多数のテキスト フィールド) があります。

私たちはsearching based of an index, not the primary key（少なくとも通常の条件下では、インデックスが使用されていることを確認しました）

テーブルは、単一プロセスの永続ストアとして使用されています。Windows で Java クライアントを使用して PostgresQL を使用する。

insert and update performanceクエリのパフォーマンスを維持するためにあきらめても構わないと思っています。

アプリケーションに影響を与えることなく定期的にインデックスを削除および再構築できるように、データがさまざまな動的テーブルに分散されるように、アプリケーションを再構築することを検討しています。ただし、いつものように、これを機能させるには時間がかかります。構成または使用法に基本的なものが欠けているのではないかと思います。

と を検討forcing vacuumingしrebuild to run at certain timesましたが、 と思われlocking period for such an action would cause our query to blockます。これはオプションかもしれませんが、リアルタイム (3 ～ 5 秒のウィンドウ) の影響があり、コードに他の変更を加える必要があります。

追加情報: 表と索引

分析:

と、はい、色々あるのは承知しておりますwe could do to normalize and improve the design of this table。これらのオプションの一部を利用できる場合があります。

この質問での私の焦点は、理解についてhow PostgresQL is managing the index and query over time (understand why, not just fix)です。やり直しや大幅なリファクタリングを行うと、多くの変更が発生します。

実行速度が非常に遅いクエリのtkprof出力は次のとおりです（警告：長いです:-)）：

オラクルのスキップスキャンに関するドキュメントを読んだところによると、スキップスキャンは、インデックスの最初の列の一意の値の数が少ない場合に最も役立ちます。重要なのは、この列の最初のインデックスには多数の一意性があるということです。だから私はスキップスキャンがここで行うのは間違っていると仮定して正しいですか？また、どのようなスキャンを行う必要がありますか？このクエリに対してもう少しヒントを与える必要がありますか？

編集IDX_MBR_IDENTFN：クエリのwhere句は、そのインデックスにあるもの以外の列ではなく、の列を使用することも指摘しておく必要があります。私が知る限り、私はどの列もスキップしていません。

編集2：このクエリを高速化するためにいくつかのことを行いました。まず、ページングを削除しました。結局のところ、このクエリはとにかく1行しか返しません。次に、LEADINGテーブルが正しい順序でクエリされていることを確認するためのヒントを追加しました。第三に、重複するmbr_idn述語を削除しました。最後に、私はIDX_MBR_IDENTFNユニークにしました。全体として、これによりパフォーマンスが大幅に向上します（ただし、実行しているクエリの中で最もコストがかかります）。

以下のように、列の値をそれ自体と比較するマルチテーブルSELECTクエリがあります。

これは私には冗長に思えます。私の質問は、それらを削除するとロジック/パフォーマンスに影響がありますか？

前もって感謝します。

実行速度が遅いクエリがあります。一般的に、パフォーマンスを高速化し、結合を制限し、単純なクエリの代わりにプロシージャを使用することを知っています。ビジネス ルールにより、procs を使用できません。もう、思いつく限り結合数を減らしました。

クエリ チューニングの次のステップは何ですか?

複雑なクエリ（サブクエリを含むクエリ）のコストを見つけようとすると、値が0になります 。mysqlのマニュアルには次のように書かれています：

「Last_query_cost の値は、サブクエリや UNION を使用した複雑なクエリではなく、単純な「フラット」クエリでのみ正確に計算できます。後者の場合、値は 0 に設定されます。

私の質問は、複雑なクエリのコストをどのように計算するのですか?

いくつかのクエリに対して sql チューニング タスクを作成し、実行しました。レポートを生成した後、次のコマンドを実行することをお勧めします。

しかし！もちろん、私はこのプロファイルが何をするのか知りたいです?! インターネットでこの質問を検索した後、次のクエリを見つけました。

このクエリの結果は次のとおりです。

私はそれが何をするのか理解していません:(そして、このプロファイルヒントをより読みやすい（/ +ヒント/）SQLヒントに変換したいですか？

私はいくつかの数値列を含むテーブルを持っていますが、ほとんどの場合それから恩恵を受けるので、それらを数値に保つ必要があります。しかし、部分一致を使用してこれらの列で一般的な検索を行う必要もあるため、whereステートメントでは次のようになります。

私の質問は：

列をCHARにキャストするnum_col1に関数ベースのインデックスを作成できますか？やってみましたが、出来ないようです。

いいえの場合、クエリの結果を高速化する方法について他に何か提案はありますか？

いくつかの可能な解決策は、元のテーブルのビューを作成し、列タイプをvarcharに変更してその列にインデックスを付けるか、別の解決策として、テーブルにvarchar列を追加してインデックスを付けることです。すでに大量の行と大量の列を含む非常に大きなテーブルがあるため、これらのソリューションの両方を避けたいと思います。

皆さん、ベスト、Nに事前に感謝します。

SELECTステートメントで代わりに実際の列名を使用すると、SQLクエリの実行が速くなるのはなぜSELECT *ですか？

特別な形式のequijoinを使用するこの特定のスクリプトに出くわしました。

なぜ等結合にゼロが追加されるのですか？インデックス検索を回避することと関係があることを知りましたが、それでも誰かが同じことの全体像を説明することができます。前もって感謝します

編集 ：

これは、テーブル/列の宣言に関連するものではありません。私の知る限り、これはSQLチューニングと関係があります。

これは私が見つけたものです：-

1. これは小さなテーブルで使用されます。
2. 通常のようにインデックス検索を行う代わりに、これはテーブル全体を一度に検索します。

しかし、通常の等結合との違い、さらにはインデックス作成がパフォーマンスにどのように影響するかを正確に知りません。

誰かが特定の文脈の中で説明し、私の発見が間違っているかどうかを知らせてくれると本当に助かります。同じためにあなたの時間と努力に感謝します:-)

列の説明：

両方のテーブルの割り当てステータスタイプIDは、NUMBER（9）として宣言されています。

オラクルのCBO（最近のバージョン）は非常に優れているため、可能な限り最悪の結合順序が指定されている場合でも、CBOは自動的に最良の結合順序を取ります。それで、ORDEREDのようなヒントは最近のバージョン（10,11）で何か良いことをしますか？CBOが最適な結合順序を見逃す可能性はありますか？ありがとう。