2026年5月26日

WordPressのDBパフォーマンスをNew Relicで継続的に監視する設定手順

データベース・バックアップ

New Relic で WordPress のデータベース性能を継続的に監視するには、PHP エージェントでアプリケーション側から見たクエリの時間と遅いクエリを記録し、必要に応じてインフラエージェントの MySQL 連携でデータベースサーバー自体の指標を集め、最後に「データベースにかかる時間」を条件にしたアラートを設定します。この記事では、New Relic の導入が済んでいる、または導入を始めるところという前提で、データベースの監視に絞った設定項目と、集まったデータの読み方、WordPress でよく見つかるボトルネックとその対処を説明します。

New Relic の画面構成やメニュー名、無料枠の範囲は頻繁に変わります。ここでは機能を目的で説明し、操作の細部は公式ドキュメントで確認していただく形にしています（2026年10月現在）。

監視の全体像

データベースの性能を見る方法は、大きく2つあります。

アプリケーション側（APM）: PHP エージェントが WordPress のリクエストごとに、どのテーブルへの SELECT や UPDATE にどれだけ時間がかかったかを記録します。「どのページで、どのクエリが遅いか」が分かります。
データベース側（インフラ）: インフラエージェントと MySQL 連携が、接続数、InnoDB のバッファプールの使用状況、遅いクエリの件数などを集めます。「データベースサーバーが全体として苦しいか」が分かります。

WordPress の改善につなげやすいのは APM 側のデータです。まず APM を設定し、データベースサーバーを別に立てている場合や、負荷の原因がアプリ以外にもありそうな場合にインフラ側を追加する、という順番が扱いやすいでしょう。

PHP エージェントのデータベース関連の設定

PHP エージェントのインストールは、New Relic の画面の案内か公式ドキュメントに従ってください。導入後は newrelic.ini（PHP の設定ディレクトリ内に置かれます）で、データベースに関わる次の項目を確認します。

; newrelic.ini（抜粋）。場所は PHP のバージョンと配布元で異なる
newrelic.license = "your-license-key"
newrelic.appname = "example.com (production)"

; トランザクショントレース（遅いリクエストの詳細）を有効にする
newrelic.transaction_tracer.enabled = true
newrelic.transaction_tracer.detail = 1

; 遅い SQL を記録する
newrelic.transaction_tracer.slow_sql = true
; SQL 文の値の部分を伏せて送る（個人情報を送らないため obfuscated を維持）
newrelic.transaction_tracer.record_sql = "obfuscated"
; しきい値を超えたクエリについて EXPLAIN の結果も記録する
newrelic.transaction_tracer.explain_enabled = true
newrelic.transaction_tracer.explain_threshold = 500

; どのデータベース・ホストへのクエリかを記録する
newrelic.datastore_tracer.database_name_reporting.enabled = true
newrelic.datastore_tracer.instance_reporting.enabled = true

各項目のポイントは次のとおりです。

record_sql は obfuscated のままにします。raw にすると、ログイン名やメールアドレス、注文情報などがクエリの値として New Relic に送られる可能性があります。個人情報を外部サービスに送ることになるため、プライバシーポリシーとの整合も考える必要があります。
explain_threshold はミリ秒で、これより遅いクエリについて EXPLAIN（実行計画）を記録します。インデックスが使われているかどうかを後から確認できます。
1台のサーバーに複数の WordPress を置いている場合は、サイトごとに appname を分けると、どのサイトのクエリかを取り違えずに済みます。PHP-FPM のプールごとに php_value[newrelic.appname] を設定する方法や、wp-config.php の先頭で newrelic_set_appname() を呼ぶ方法があります。

// wp-config.php の先頭付近。拡張が読み込まれていない環境でもエラーにならないようにする
if ( extension_loaded( 'newrelic' ) && function_exists( 'newrelic_set_appname' ) ) {
    newrelic_set_appname( 'example.com (production)' );
}

設定を変えたら PHP-FPM を再起動します（例: sudo systemctl restart php8.3-fpm）。PHP エージェントは WordPress を自動で認識し、フックやプラグインごとの処理時間も記録できます。この機能の有無や設定項目はエージェントのバージョンで変わっているため、使っているバージョンの説明を確認してください。

データベースサーバーの指標を集める（必要な場合）

インフラエージェントを入れたサーバーでは、MySQL 連携（on-host integration）を追加すると、データベースサーバーの内部の指標を集められます。そのために、権限を絞った監視専用のユーザーを作ります。

-- 監視専用ユーザー。パスワードは推測されにくいものに置き換える
CREATE USER 'newrelic'@'localhost' IDENTIFIED BY 'your-strong-password';
GRANT REPLICATION CLIENT ON *.* TO 'newrelic'@'localhost' WITH MAX_USER_CONNECTIONS 5;

WordPress の接続ユーザーを監視に流用すると、書き込み権限まで渡すことになるため避けます。連携の設定ファイルの場所や書式は公式ドキュメントの MySQL 連携のページを参照してください。設定ファイルには監視用ユーザーのパスワードが入るため、ファイルの権限を絞り、Git などで共有しないようにします。

集まったデータの読み方

データベースの画面で見るところ

APM のデータベース（Databases）の画面では、テーブルと操作の組み合わせ（例: wp_options の select、wp_postmeta の select）ごとに、合計時間・平均時間・呼び出し回数が並びます。注目するのは「合計時間が大きいもの」です。1回は速くても大量に呼ばれているクエリは、遅いクエリ1本より影響が大きいことがあります。

遅いクエリとトランザクショントレース

遅いクエリの一覧（Slow SQL）では、しきい値を超えたクエリと、それを発行したトランザクション（URL やフック）、記録されていれば EXPLAIN の結果を確認できます。EXPLAIN で type が ALL（全件走査）になっている、rows が非常に大きい、といったクエリが改善の候補です。

WordPress でよく見つかるボトルネックと対処

wp_options の大量・重い読み込み: 自動読み込みされるオプションが肥大化していると、毎回のリクエストで大きなデータを読みます。不要になったプラグインのデータを確認し、Redis などの永続オブジェクトキャッシュの導入も検討します。
wp_postmeta への meta_query: カスタムフィールドで絞り込むクエリは、meta_value にインデックスが効きにくく、記事数が増えると遅くなります。タクソノミーで分類できないか、検索条件を減らせないかを先に考えます。
件数の数え上げ: 一覧の総件数が不要な WP_Query では no_found_rows を true にすると、総件数を求める処理を省けます。ID だけが必要なら fields を ids にします。
バックグラウンド処理のテーブル: WooCommerce などが使う Action Scheduler のテーブルに完了済みの記録が溜まると、クエリが遅くなることがあります。保存期間の設定や整理の方法は各プラグインの説明に従います。

修正はステージング環境で試し、本番では変更前後の同じ時間帯のデータを比べて効果を確かめます。インデックスの追加などデータベースの構造を変える場合は、事前にバックアップを取ってください。

継続監視のためのアラート設定

画面を見に行かなくても異常に気づけるよう、アラートを設定します。NRQL（New Relic のクエリ言語）で条件を書くと、データベースに絞った条件を作れます。

-- リクエストあたりの平均データベース時間（秒）
SELECT average(databaseDuration) FROM Transaction
WHERE appName = 'example.com (production)'

-- リクエストあたりの平均クエリ発行回数
SELECT average(databaseCallCount) FROM Transaction
WHERE appName = 'example.com (production)'

しきい値は、まず1〜2週間の平常時の値を観察してから決めます。最初から厳しくすると通知が多すぎて見なくなるため、平常時の2〜3倍程度の値で「一定時間続いたら通知」にする方が運用しやすくなります。クエリ回数の急増は、プラグインの更新でキャッシュが効かなくなった、ループ内でクエリを発行するコードが入った、といった変化の早いサインになります。

送るデータ量が増えると、無料枠や契約の範囲を超えることがあります。トレースの詳細度や対象のアプリを必要な範囲に絞り、データの取り込み量は管理画面で定期的に確認してください。

まとめ

APM（PHP エージェント）で「どのクエリが遅いか」を、必要に応じてインフラの MySQL 連携で「データベース全体の負荷」を見る。
newrelic.ini では slow_sql と explain を有効にし、record_sql は obfuscated のままにして個人情報を送らない。
監視用の MySQL ユーザーは権限を絞って専用に作り、WordPress のユーザーを流用しない。
データベースの画面では合計時間の大きいクエリから見て、wp_options、meta_query、件数の数え上げなどを順に疑う。
databaseDuration や databaseCallCount を条件にしたアラートを、平常時の値を見てから設定する。