WordPressのデータベースモニタリングツール比較｜Query Monitor・スロークエリログ・PMM・New Relicの使い分け

WordPressのデータベース監視は、「1ページの中でどのクエリが遅いか」を見る道具と、「サーバー全体で何が負荷になっているかを継続的に記録する」道具に分けて考えると選びやすくなります。前者はQuery Monitor、後者はMySQLのスロークエリログやPerformance Schema、さらに継続監視が必要ならPercona Monitoring and Management（PMM）やNew Relicなどが候補です。この記事では、主なツールの得意分野と導入の手間を比較し、サイトの規模や体制に合わせた組み合わせ方を解説します。

比較の前に：何を知りたいのかを決める

データベースの監視と一口に言っても、知りたいことによって適したツールが違います。

• 特定のページや管理画面が遅い原因：そのリクエストで実行されたクエリと、それを発行したプラグインやテーマを知りたい
• 時間帯によって遅くなる原因：いつ、どのクエリが重かったかを後から振り返りたい
• サーバーの余力：接続数、メモリ、ディスクの読み書きが限界に近づいていないかを把握したい
• 障害の早期発見：データベースが止まったり、応答が極端に遅くなったりしたら通知がほしい

最初の目的なら開発・調査用のツールで足ります。2つ目以降は、常時データを記録する仕組みが必要です。

主なツールの比較

料金や提供機能は変わることがあるため、有料サービスは公式サイトで最新の情報を確認してください（2026年10月現在の情報に基づく比較です）。

Query Monitor：ページ単位の原因調査

Query Monitorは、管理者としてログインした状態でページを開くと、そのリクエストで実行されたクエリの一覧、実行時間、呼び出し元を管理バーから確認できるプラグインです。

wp plugin install query-monitor --activate

調査で特に役立つのは次の表示です。

• 遅いクエリ：一定時間を超えたクエリが強調表示されます。
• 重複クエリ：同じクエリが何度も実行されている箇所が分かります。ループの中で毎回データを取得しているテーマやプラグインを見つけるのに有効です。
• コンポーネント別の集計：本体、テーマ、各プラグインのどれが多くのクエリを発行しているかを比較できます。

Query Monitorの情報は、ログインしている管理者にしか表示されません。ただし、計測のための処理が加わるため、調査が終わったら停止するか、ステージング環境で使うのが無難です。また、記録が残るのはそのページを開いた瞬間だけなので、「深夜だけ遅い」といった問題の調査には向きません。

なお、プラグインを入れずに確認する方法として、wp-config.php に define( 'SAVEQUERIES', true ); を加えると、$wpdb->queries に実行したクエリと時間、呼び出し元が記録されます。本番で常時有効にするとメモリを消費するため、調査時だけ使います。

スロークエリログ：遅いクエリを継続的に記録する

MySQLのスロークエリログは、設定した時間より長くかかったクエリをファイルに記録する機能です。追加のソフトウェアが不要で、サーバー全体を対象にできるため、継続監視の第一歩として向いています。

設定を変える前に、現在の値を確認します。

SHOW VARIABLES LIKE 'slow_query%';
SHOW VARIABLES LIKE 'long_query_time';

再起動後も有効にするには、MySQLの設定ファイルに記述します。設定ファイルの場所はディストリビューションによって異なります。変更前に設定ファイルのバックアップを取ってください。

[mysqld]
slow_query_log = ON
slow_query_log_file = /var/log/mysql/mysql-slow.log
# 1秒を超えたクエリを記録する
long_query_time = 1

long_query_time を小さくしすぎると、ログが急速に大きくなります。最初は1秒程度から始め、ログの量を見ながら調整します。ログファイルのローテーションも設定しておいてください。

記録したログは、そのままでは読みにくいため集計ツールを使います。MySQLに付属する mysqldumpslow や、Percona Toolkitの pt-query-digest が定番です。

# 合計時間の長い順に上位10件を表示
mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log

# Percona Toolkit がある場合は、クエリの種類ごとに詳しく集計できる
pt-query-digest /var/log/mysql/mysql-slow.log > slow-report.txt

WordPressでよく見つかるのは、wp_postmeta を値で検索するクエリ、件数の多い wp_options の読み込み、検索機能の LIKE '%...%' などです。

Performance Schemaとsysスキーマ：設定変更なしで集計する

MySQL 5.7以降では、Performance Schemaとsysスキーマを使って、どのクエリが合計で最も時間を使っているかを集計できます。多くの環境で初期状態から有効になっているため、スロークエリログを設定する前の当たりづけに便利です。

-- 合計実行時間の長いクエリ上位10件
SELECT query, db, exec_count, total_latency, avg_latency
FROM sys.statement_analysis
LIMIT 10;

sys.statement_analysis は、初期状態で合計実行時間の長い順に並んでいます。集計はMySQLの再起動でリセットされるため、長期の傾向を見るには向きません。MariaDBではsysスキーマの有無や内容が異なるので、利用中のバージョンの公式ドキュメントを確認してください。

サーバー全体の状態は、ステータス変数でも確認できます。

SHOW GLOBAL STATUS WHERE Variable_name IN
  ('Threads_connected', 'Max_used_connections', 'Slow_queries', 'Uptime');

Max_used_connections が max_connections の設定値に近い場合は、接続数の不足で「データベース接続確立エラー」が起きる可能性があります。

PMM・New Relic・監視基盤：継続的な可視化と通知

Percona Monitoring and Management（PMM）

PMMは、Perconaが提供するオープンソースの監視ツールです。監視用のサーバーを1台用意し、データベースサーバーにエージェントを入れると、クエリの統計とサーバーの指標をグラフで確認できます。スロークエリログやPerformance Schemaの情報を集計して見やすくしてくれるため、VPSや専用サーバーでMySQLを自分で運用している場合に向いています。監視サーバーの構築と保守が必要になる点が負担です。

New Relic

New RelicはPHPエージェントを入れることで、WordPressの処理時間のうちデータベースが占める割合や、遅いクエリを発行した処理をアプリケーション側から追えるサービスです。データベースだけでなく外部APIの呼び出しやPHPの処理時間もまとめて見られ、通知の設定もできます。無料枠がありますが、データ量や利用者数によって料金がかかります。共有のレンタルサーバーではPHPエージェントを入れられないことが多い点に注意してください。

Prometheus・Zabbixなど既存の監視基盤

すでにサーバー監視にPrometheusやZabbixを使っているなら、MySQL用のエクスポーターやテンプレートを追加して、接続数やクエリ数を同じ画面で監視する方法もあります。クエリ単位の分析は弱いため、スロークエリログと組み合わせて使います。

マネージドデータベースの場合

Amazon RDSなどのマネージドデータベースを使っている場合は、クラウド側の監視機能でクエリの負荷や待機の内訳を確認できます。サーバーに直接ログインできないため、スロークエリログもクラウドの管理画面やログ転送の設定から有効にします。

規模別のおすすめの組み合わせ

• 共有レンタルサーバーの小規模サイト：Query Monitorで遅いページを調査します。サーバー全体の監視はサーバー会社の範囲になるため、管理画面で確認できる負荷のグラフやログを活用します。
• VPSで運用する中規模サイト：スロークエリログを常時有効にし、定期的に pt-query-digest で集計します。必要に応じてPMMを追加します。
• 複数サーバーや事業の中核となるサイト：New RelicやPMMで継続監視と通知を設定し、原因の詳細はQuery Monitorやスロークエリログで掘り下げます。

どのツールを使っても、大切なのは遅いクエリを見つけた後の対処です。インデックスの追加やクエリの書き換えはデータベースに変更を加える作業なので、事前にバックアップを取り、ステージング環境で効果を確かめてから本番に反映してください。

まとめ

• 監視の目的を「ページ単位の原因調査」と「サーバー全体の継続監視」に分けて、ツールを選びます。
• Query Monitorは導入が簡単で原因の特定に強い一方、継続的な記録はできません。
• スロークエリログと mysqldumpslow・pt-query-digest は、追加費用なしで始められる継続監視の基本です。
• sysスキーマはすぐに使える集計手段ですが、再起動で集計がリセットされます。
• PMMやNew Relicは継続的な可視化と通知に向いており、運用体制や費用と見合うかで判断します。

• Query Monitorの使い方とデバッグ方法
• MySQLのスロークエリログを設定する方法