メインコンテンツにスキップ
モジュール 10 · レッスン 2 / 4コース内の 38/57~15 min
モジュールのレッスン (2/4)

説明と分析

作成したばかりの優れたインデックスを使用するかどうかをデータベースがどのように「選択」するのか疑問に思ったことはありますか? クエリ (たとえば、チェーンされたグループによる長い結合) で Enter キーを押すとすぐに、クエリ プランナー はクエリを実行するために数十の戦略をその場で計算し、理論上最も速いと考えられる戦略を選択します。

しかし、開発者としては、クエリ プランナーの暗い心の内部を覗くことができる必要があります。

説明する

Planner がどのように処理を進めるつもりかを確認するには、クエリの先頭にマジック ワード EXPLAIN を入力するだけです。

SQL
EXPLAIN SELECT * FROM orders WHERE status = 'delivered';

結果は命令ではありません!代わりに、出力に計画が表示されます (推定統計情報を含む)。

Code
Seq Scan on orders  (cost=0.00..25.88 rows=15 width=40)
  Filter: (status = 'delivered'::text)

これは次のことを示しています。

  1. Planner は Seq Scan (ディスク全体のブルートなシーケンシャル読み取り) を使用します。何十億もの注文がある場合は問題があります。
  2. 約 15 行が返されると推定し、プリロードされた CPU サイクルで「コスト」を計算します。

分析の説明

EXPLAIN は (データに対して過去数時間に計算されたグローバル統計に基づく) アルゴリズムの推測に依存しますが、EXPLAIN ANALYZE 実際にクエリを実際に実行します (そして完全な論理結果を待ちます)。実際の経過時間を数学的に絶対的な条件で比較します。

SQL
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 90;
Code
Index Scan using idx_orders_cust on orders  (cost=0.15..8.13 rows=4 width=40) (actual time=0.012..0.015 rows=4 loops=1)
  Index Cond: (customer_id = 90)
Planning Time: 0.081 ms
Execution Time: 0.033 ms

万歳!ここでは、データベースがセカンダリ idx_orders_cust インデックスに インデックス スキャン を適用することを決定し、1,000 分の 1 秒という微細な実行時間を要し、数百万行をその場でスキップすることを決定したことがわかります。

あなたの番です

運動#sql.m10.l2.e1
試行回数: 0読み込み中…

基本的な EXPLAIN コマンドを作成して、PostgreSQL が現在の在庫が 10 ユニット未満の製品をどのように検索するかを確認します。 (このステップでは ANALYZE を使用しないでください。)

エディターを読み込み中…
ヒントを表示

既存のステートメントの先頭に EXPLAIN という単語を追加するだけです。

3 回の試行後に解決策が利用可能になります

真実の指標を取得する

運動#sql.m10.l2.e2
試行回数: 0読み込み中…

数学的に推測されたスケッチではなく、実際のパフォーマンス診断 (タイミングとサイクル) が必要です。\n専用のステートメントを使用して、実際に実行して、2025 年 1 月 1 日より前にサインアップしたすべての「顧客」のルックアップ ('signed_up_on' < '2025-01-01') を調べます。

エディターを読み込み中…
ヒントを表示

EXPLAIN の直後に ANALYZE という単語を追加します。

3 回の試行後に解決策が利用可能になります