TableStudioでクエリを高速化する
TableStudioは、推測ではなく測定できます。以下ツールで証明できるのに、直感でインデックスや書き換えを推奨しないでください。これらはほとんどがPostgreSQL専用です。他のエンジンではexplain_queryを使用し、実行計画から推論してください。
まず、データベースワークフロースキルに従って接続を選択します。現実的なデータを持つデータベースに対して分析を実行することを推奨します。ほぼ空の開発データベースは誤解を招く実行計画を生成します。
遅い箇所を見つける
- ユーザーがクエリまたはエンドポイントを指定した場合: 実行されるSQLを（コードまたはORMのログから）見つけ、「単一ステートメントの診断」に進みます。
- 「データベースが遅いのはなぜ？」:
slow_queriesを呼び出します。これはpg_stat_statementsから総時間でステートメントをランク付けします。各行のquery_idを保持しておいてください。他のツールがそれを受け入れます。拡張機能がインストールされていない場合、ツールは有効化に必要な手順を説明するので、求めずにインストールするのではなく、その情報を伝えてください。 - 広範なチューニング:
workload_index_advisorは、最も多くのデータベース時間をカバーする最小限のインデックスを見つけ、使用されていない既存のインデックスをリストします。
健全性チェック
ユーザーがデータベースの問題を尋ねたり、全般的なレビューを求めてきた場合、何も変更せずに以下を報告します。
database_health。そのunavailableリストを要約より先に読んでください。エントリがあるのに空の検出結果は、すべてが正常であることを意味するのではなく、チェックがスキップされたことを意味します。database_overview：サイズ、最大かつ最もビジーなテーブル、および接続数。schema_issues（tableなし）：データベース全体の設計上の問題。
最も重要な検出事項をわかりやすい言葉で最初に配置します。何が問題か、無視した場合のコスト、修正方法。各検出事項のverify_sqlを含め、ユーザーが数値を確認できるようにし、修正がある場合はそのlock_impactも含めます。ユーザーが選択した修正を以下の「Ship it」を通じて適用することを提案します。
単一ステートメントの診断
optimize_queryにSQL（およびslow_queriesから来た場合はquery_id）を渡します。読み取り専用ステートメントの場合は、analyze: trueを渡して測定チェックを実行できるようにします。これはロールバックトランザクション内で1回実行されます。already_fastを報告した場合は、何もする価値がないことを意味します。そのように伝え、改善をでっち上げないでください。- 詳細が必要な場合は、
explain_queryを使用します（読み取り専用の場合はanalyze: true）。各ノードのactual_rowsとestimated_rowsを比較します。大きな差は古い統計（テーブルをANALYZE）を示しており、多くの場合、欠落したインデックスではなく、これが実際のバグです。 $1, $2プレースホルダーを持つステートメントは、適切に計画するために実際の値が必要です。suggest_parameter_valuesは、履歴、ライブセッション、統計からそれらを見つけます。
修正を証明する
何かを推奨する前に、benchmark_query_variants（クエリラボ）を使用します。
- ベースラインのSQLと、
variantsとして候補（書き換えたsql、hypothetical_indexes（hypopgで計画され、決して構築されない）、hide_indexes、またはプランナーsettings）を渡します。またはvariantsを省略してfind_fasterに独自の提案を任せます。 - 各パラメータセットに対していくつかの実行の中央値を報告し、すべての書き換えがベースラインと同じ行を返すことを確認します。
same_rowsがyesのバリアントのみを推奨します。recommendation内のバリアントを優先します。測定された前後の値を引用し、直感に基づくパーセンテージは使用しません。
インデックスを削除する前（未使用または重複）に、index_what_ifをhideでそのインデックスを指定して実行します。コストが高くなるステートメント、または現在そのインデックスを使用しているステートメントがあれば、影響を受けます。
出荷する
インデックスと書き換えは、データベースワークフロースキルの通常の変更フローを通じて行われます。
- インデックス変更はスキーマ変更です。リポジトリにマイグレーションツールがある場合は、そこにインデックスを追加します。それ以外の場合は、
stage_migrationを使用して提案し、rationaleに測定値を含めます。 - PostgreSQLでは、トラフィックのあるテーブルには
CREATE INDEX CONCURRENTLYを使用し、トランザクションでラップしないでください。 - クエリ書き換えはコード変更です。それを発行するコードを編集し、サマリーにベンチマーク結果を記載します。