RDBの運用で使うCRUD以外のクエリまとめ

PostgreSQL監視メトリクス クエリ辞書

更新日: 2026-03-14
対象資料: PostgreSQL 公式ドキュメント / 27.2 Statistics Monitoring

1. この資料の目的

このメモは、PostgreSQL を監視するときによく使う統計ビューとクエリを、初心者向けにまとめたものです。

「どの画面やSQLを見ればよいか分からない」
「専門用語が多くて読みづらい」
という場面で、最初の参照先として使うことを想定しています。

2. まず覚えたい用語

セッション

DBに接続している1つ1つの利用者や処理のことです。
アプリやSQLクライアントが接続すると、通常は1接続ごとに1セッションできます。

待機イベント

処理が何かを待って止まっている状態です。
たとえば、次のような理由で待つことがあります。

• データの読み書きが終わるのを待っている
• 他の処理が使っている行やテーブルの解放を待っている
• ネットワークや送信先の応答を待っている

ロック

同じデータを同時に壊さないようにするための「使用中マーク」のようなものです。
ロック自体は普通の仕組みですが、長く待たされると遅延や詰まりの原因になります。

レプリケーション

DBの内容を別サーバーへコピーし続ける仕組みです。
本番DBから待機系DBへデータを送る用途でよく使います。

WAL

データ変更を記録するログです。
障害復旧やレプリケーションで使われます。更新が多いとWALも増えます。

VACUUM

更新や削除で不要になった領域を整理する仕組みです。
不足するとテーブルがふくらみやすくなり、性能劣化の原因になります。

ANALYZE

PostgreSQL が実行計画を決めるための統計情報を更新する処理です。
古いままだと、効率の悪いSQL実行につながることがあります。

累積値

起動後または統計リセット後から、ずっと足し上がっていく値です。
監視では「今の値」ではなく「前回との差分」を見るのが基本です。

3. 最初に見るべきビュー

迷ったら、まず次の5つを見ると全体像をつかみやすいです。

• pg_stat_activity
  • 今、誰が何をしているかを見る
• pg_stat_database
  • DB全体の忙しさやエラー傾向を見る
• pg_stat_user_tables
  • テーブルの更新状況や肥大の気配を見る
• pg_stat_user_indexes
  • インデックスが使われているかを見る
• pg_stat_replication
  • 待機系DBへのデータ転送遅れを見る

4. 監視メトリクス辞書

ビュー	何を見るものか	よく使う列	初心者向けの見方	公式リンク
pg_stat_activity	今つながっている接続と実行中SQL	usename, state, wait_event, query_start, query	遅いSQLや詰まっている処理を見つける	pg_stat_activity
pg_stat_database	DB全体の累積統計（起動後から足し上がる値）	xact_commit, xact_rollback, blks_read, blks_hit, temp_bytes, deadlocks	忙しさ、失敗、キャッシュ効率を見る	pg_stat_database
pg_stat_user_tables	テーブルごとの利用状況	seq_scan, idx_scan, n_live_tup, n_dead_tup, last_autovacuum	フルスキャンが多い表や肥大気味の表を探す	pg_stat_user_tables
pg_stat_user_indexes	インデックス（検索を速くする索引）の利用状況	idx_scan, idx_tup_read, idx_tup_fetch	使われていないインデックス候補を探す	pg_stat_user_indexes
pg_stat_replication	レプリケーション（別サーバーへのコピー）の状態	state, write_lag, flush_lag, replay_lag	待機系への反映遅れを確認する	pg_stat_replication
pg_stat_wal	WAL（更新ログ）の増え方	wal_records, wal_fpi, wal_bytes	更新量が急増していないかを見る	pg_stat_wal
pg_stat_io	I/O（ディスク読み書き）の詳細	backend_type, object, context, reads, writes, fsyncs	誰が多く読み書きしているかを見る	pg_stat_io
pg_statio_user_tables	テーブル単位のI/O（ディスク読み書き）	heap_blks_read, heap_blks_hit	テーブルごとのキャッシュ効率を見る	pg_statio_user_tables
pg_stat_user_functions	関数の実行統計	calls, total_time, self_time	重い関数を探す	pg_stat_user_functions
pg_stat_archiver	WALアーカイブ（ログ退避）の成否	成功回数、失敗回数など	アーカイブに失敗していないか見る	pg_stat_archiver

5. まず使うクエリ集

5.1 長時間動いているSQLを探す

SELECT
  pid,
  datname,
  usename,
  state,
  wait_event_type,
  wait_event,
  now() - query_start AS duration,
  query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY duration DESC;

何が分かるか:

• 今まさに長く動いているSQL
• 途中で何かを待って止まっているセッション

見方:

• duration が長いものから確認します
• wait_event が入っていれば、何かを待っている可能性があります
• state = active なら実行中、idle は何もしていない待機状態です

5.2 待ちが発生しているセッションを見る

SELECT
  pid,
  usename,
  datname,
  state,
  wait_event_type,
  wait_event,
  query
FROM pg_stat_activity
WHERE wait_event_type IS NOT NULL
ORDER BY query_start;

何が分かるか:

• 何かを待って止まっているセッション

見方:

• 長く待っているものは、詰まりの原因候補です
• ロック待ち（他の処理が先に同じデータを使っていて待たされている状態）なら、詰まりの可能性があります

5.3 DB全体のキャッシュ効率を見る

SELECT
  datname,
  blks_hit,
  blks_read,
  ROUND(
    100.0 * blks_hit / NULLIF(blks_hit + blks_read, 0),
    2
  ) AS cache_hit_ratio_pct
FROM pg_stat_database
WHERE datname IS NOT NULL
ORDER BY cache_hit_ratio_pct ASC;

何が分かるか:

• メモリ上のキャッシュがどれくらい効いているか

見方:

• 一般に高いほど、ディスク読み込みが少なく効率的です
• 低すぎる場合は、読み込み負荷やメモリ不足の可能性があります

5.4 ロールバック率を見る

SELECT
  datname,
  xact_commit,
  xact_rollback,
  ROUND(
    100.0 * xact_rollback / NULLIF(xact_commit + xact_rollback, 0),
    2
  ) AS rollback_ratio_pct
FROM pg_stat_database
WHERE datname IS NOT NULL
ORDER BY rollback_ratio_pct DESC;

何が分かるか:

• 正常終了せず取り消された処理が多いか

見方:

• ロールバック（途中までの処理を取り消すこと）率が高い場合、アプリ側エラーや再試行の多発を疑います

5.5 一時ファイルを多く使うDBを見る

SELECT
  datname,
  temp_files,
  pg_size_pretty(temp_bytes) AS temp_bytes
FROM pg_stat_database
WHERE datname IS NOT NULL
ORDER BY temp_bytes DESC;

何が分かるか:

• 一時的な作業用ファイルを多く使っているDB

見方:

• ソートや集計が重いと増えやすいです
• 多すぎるとディスクI/O増加につながります

5.6 デッドロック（お互いに待ち合って進めなくなる状態）発生数を見る

SELECT
  datname,
  deadlocks
FROM pg_stat_database
WHERE datname IS NOT NULL
ORDER BY deadlocks DESC;

何が分かるか:

• お互いに待ち合って処理が進めなくなった回数

補足:

• デッドロック（お互いに待ち合って進めなくなる状態）は「AがBを待ち、BもAを待つ」ような状態です
• 発生するとどちらかの処理が失敗させられます

5.7 フルスキャンが多いテーブルを見る

SELECT
  schemaname,
  relname,
  seq_scan,
  idx_scan,
  n_live_tup
FROM pg_stat_user_tables
ORDER BY seq_scan DESC
LIMIT 20;

何が分かるか:

• インデックスを使わず、表全体を読んでいる回数が多いテーブル

見方:

• seq_scan が多いから必ず悪い、ではありません
• ただし大きい表で多い場合は、インデックスやSQL見直し候補です

5.8 Dead tuple（更新や削除で不要になった古い行）が多いテーブルを見る

SELECT
  schemaname,
  relname,
  n_live_tup,
  n_dead_tup,
  ROUND(
    100.0 * n_dead_tup / NULLIF(n_live_tup + n_dead_tup, 0),
    2
  ) AS dead_tuple_ratio_pct,
  last_autovacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

何が分かるか:

• 更新や削除の結果、不要データがたまりつつあるテーブル

見方:

• n_dead_tup（不要になった古い行の推定数）が多いのに last_autovacuum が古い場合は要注意です
• 放置すると表がふくらみやすくなります

5.9 VACUUM（不要領域の掃除） / ANALYZE（統計情報の更新）が古いテーブルを見る

SELECT
  schemaname,
  relname,
  last_vacuum,
  last_autovacuum,
  last_analyze,
  last_autoanalyze
FROM pg_stat_user_tables
ORDER BY COALESCE(last_autoanalyze, last_analyze, last_autovacuum, last_vacuum) NULLS FIRST
LIMIT 50;

何が分かるか:

• 長い間メンテナンスされていないテーブル

見方:

• 更新が多い表なのに日時が古い場合は要確認です

5.10 使われていない可能性があるインデックス（検索を速くするための索引）を見る

SELECT
  schemaname,
  relname AS table_name,
  indexrelname AS index_name,
  idx_scan
FROM pg_stat_user_indexes
ORDER BY idx_scan ASC, indexrelname;

何が分かるか:

• あまり使われていないインデックス候補

注意:

• idx_scan = 0 だけで削除してはいけません
• 制約用、月次バッチ用、障害時の特殊クエリ用などの可能性があります

5.11 テーブルごとのキャッシュ効率（メモリ上でどれだけ読めているか）を見る

SELECT
  schemaname,
  relname,
  heap_blks_read,
  heap_blks_hit,
  ROUND(
    100.0 * heap_blks_hit / NULLIF(heap_blks_hit + heap_blks_read, 0),
    2
  ) AS heap_hit_ratio_pct
FROM pg_statio_user_tables
ORDER BY heap_hit_ratio_pct ASC NULLS FIRST
LIMIT 20;

何が分かるか:

• どのテーブルがディスクから多く読まれているか

見方:

• 大きな表で比率が低い場合は、負荷源の候補になります

5.12 重い関数を探す

SELECT
  schemaname,
  funcname,
  calls,
  ROUND(total_time::numeric, 2) AS total_time_ms,
  ROUND(self_time::numeric, 2) AS self_time_ms,
  ROUND((total_time / NULLIF(calls, 0))::numeric, 2) AS avg_time_ms
FROM pg_stat_user_functions
ORDER BY total_time DESC
LIMIT 20;

何が分かるか:

• 呼ばれる回数が多い関数
• 1回あたりが重い関数

5.13 レプリケーション（別サーバーへのコピー）遅延を見る

SELECT
  application_name,
  client_addr,
  state,
  sync_state,
  write_lag,
  flush_lag,
  replay_lag
FROM pg_stat_replication
ORDER BY application_name;

何が分かるか:

• 本番側から待機側への反映遅れ

見方:

• replay_lag が大きいと、待機系DBが最新に追いついていません

5.14 WAL（更新ログ）の増加量を見る

SELECT
  wal_records,
  wal_fpi,
  pg_size_pretty(wal_bytes) AS wal_bytes
FROM pg_stat_wal;

何が分かるか:

• 変更ログがどれくらい増えているか

見方:

• 更新系処理が増えると WAL も増えやすいです
• 監視では差分で見るのが基本です

5.15 pg_stat_io でI/O（ディスク読み書き）の多い処理を見る

SELECT
  backend_type,
  object,
  context,
  reads,
  read_time,
  writes,
  write_time,
  fsyncs,
  fsync_time
FROM pg_stat_io
ORDER BY reads DESC, writes DESC;

何が分かるか:

• どの種類の処理が多く読み書きしているか

補足:

• backend_type（そのI/Oを行っている処理の種類）は、どのタイプの処理が負荷を出しているかを見る手がかりです
• たとえば通常クエリ、バックグラウンド処理、VACUUM などを切り分けられます

6. 監視での基本的な見方

累積値（起動後から足し上がっていく値）は差分で見る

xact_commit や wal_bytes は、時間とともに増え続ける累積値です。
そのため監視では、次のように扱います。

• 1分前との差分を取る
• 5分平均で変化量を見る
• 監視ツール側で rate/sec を計算する

1つの値だけで決めつけない

たとえば次のように組み合わせて見ると判断しやすくなります。

• pg_stat_activity + wait_event
  • 今、何か待って詰まっているかを見る
• pg_stat_user_tables.n_dead_tup + last_autovacuum
  • 表がふくらみ気味で、しかも掃除が追いついていないかを見る
• pg_stat_database.temp_bytes
  • 重い集計やソートが増えていないかを見る
• pg_stat_user_indexes.idx_scan
  • 使われていないインデックス候補かを見る

7. まずはこれだけ見ればよい簡易チェック

日常確認なら、最初は次の3本でも十分です。

1. 長時間SQL確認

SELECT pid, usename, now() - query_start AS duration, state, wait_event, query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY duration DESC;

1. DB全体の状態確認

SELECT datname, xact_commit, xact_rollback, deadlocks, temp_files, temp_bytes
FROM pg_stat_database
WHERE datname IS NOT NULL
ORDER BY datname;

1. テーブル肥大（不要な古い行がたまって表がふくらむこと）の気配確認

SELECT schemaname, relname, n_live_tup, n_dead_tup, last_autovacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

8. 公式リンク集

• 27.2 Statistics Monitoring
• 27.2.3 pg_stat_activity
• 27.2.4 pg_stat_replication
• 27.2.12 pg_stat_archiver
• 27.2.13 pg_stat_io
• 27.2.14 pg_stat_bgwriter
• 27.2.15 pg_stat_checkpointer
• 27.2.16 pg_stat_wal
• 27.2.17 pg_stat_database
• 27.2.18 pg_stat_database_conflicts
• 27.2.19 pg_stat_all_tables / pg_stat_user_tables
• 27.2.20 pg_stat_all_indexes / pg_stat_user_indexes
• 27.2.21 pg_statio_all_tables / pg_statio_user_tables
• 27.2.22 pg_statio_all_indexes / pg_statio_user_indexes
• 27.2.24 pg_stat_user_functions
• 27.2.26 Statistics Functions

9. 補足

• 本資料は 2026-03-14 時点の current ドキュメントをもとに整理しています
• 実際に使える列は PostgreSQL のバージョン差分に注意してください
• pg_stat_io のように比較的新しいビューは、運用中バージョンで存在確認をしてから使ってください