MySQL の監視とヘルスチェック

MySQL を安定して運用し続けるには、サーバーの状態を継続的に監視し、問題を早期に検知する仕組みが不可欠だ。障害が起きてから対処するのではなく、予兆を捉えて未然に防ぐことが運用の質を大きく左右する。

SHOW STATUS による基本的な監視

MySQL にはサーバーの状態を数値で確認できるステータス変数が数百個用意されている。SHOW GLOBAL STATUS で一覧を取得できるが、すべてを追いかける必要はない。まずは重要な指標に絞って監視を始めるのが現実的だ。

-- 現在の接続数を確認
SHOW GLOBAL STATUS LIKE 'Threads_connected';

-- これまでの最大同時接続数
SHOW GLOBAL STATUS LIKE 'Max_used_connections';

-- スロークエリの累計数
SHOW GLOBAL STATUS LIKE 'Slow_queries';

-- テーブルロック待ちの累計
SHOW GLOBAL STATUS LIKE 'Table_locks_waited';

Threads_connected は現在アクティブな接続数を示し、max_connections の設定値に近づいていれば接続枯渇のリスクがある。Slow_queries が急増している場合は、クエリチューニングやインデックスの見直しが必要なサインとなる。

SHOW PROCESSLIST で実行中のクエリを把握する

ある瞬間にどのクエリが実行されているかを確認するには SHOW PROCESSLIST が有効だ。長時間実行されているクエリやロック待ちのセッションを素早く特定できる。

-- 実行中のプロセス一覧
SHOW FULL PROCESSLIST;

-- performance_schema からも確認可能（MySQL 5.7+）
SELECT id, user, host, db, command, time, state, info
FROM information_schema.processlist
WHERE command != 'Sleep'
ORDER BY time DESC;

Time カラムの値が異常に大きいクエリは、テーブルロックやデッドロック、非効率なフルテーブルスキャンなどの原因を抱えている可能性が高い。本番環境では定期的にこの一覧を確認する習慣をつけておくとよい。

InnoDB の状態監視

InnoDB はデフォルトのストレージエンジンであり、そのバッファプールの使用状況がパフォーマンスに直結する。

-- InnoDB バッファプールのヒット率を計算
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';

-- ヒット率 = 1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)
-- 99% 以上が理想的

Innodb_buffer_pool_read_requests はバッファプールへの読み取り要求の総数で、Innodb_buffer_pool_reads はディスクから読み込む必要があった回数を表す。ヒット率が 99% を下回っているなら、innodb_buffer_pool_size の増加を検討すべきだろう。

バッファプールヒット率が高い状態

ほとんどのデータ読み取りがメモリ上で完結し、ディスク I/O が最小限に抑えられている。レスポンスタイムも安定する。

バッファプールヒット率が低い状態

頻繁にディスクからデータを読み込む必要があり、I/O がボトルネックになりやすい。クエリのレスポンスタイムが不安定になる原因となる。

performance_schema を活用した詳細監視

MySQL 5.7 以降では performance_schema がデフォルトで有効になっており、サーバー内部の動作を詳細に把握できる。特にクエリの実行統計は events_statements_summary_by_digest テーブルに集約されている。

-- 実行回数が多く、平均実行時間が長いクエリを特定
SELECT
  DIGEST_TEXT,
  COUNT_STAR AS exec_count,
  ROUND(AVG_TIMER_WAIT / 1000000000, 2) AS avg_ms,
  ROUND(SUM_TIMER_WAIT / 1000000000, 2) AS total_ms
FROM performance_schema.events_statements_summary_by_digest
WHERE SCHEMA_NAME IS NOT NULL
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;

この結果から、チューニング効果の高いクエリを優先的に特定できる。実行回数が多く平均実行時間も長いクエリは、わずかな改善でもシステム全体への影響が大きい。

スロークエリログの設定と活用

スロークエリログは、指定した閾値を超えて実行に時間がかかったクエリを記録する機能だ。パフォーマンス問題の調査において最も基本的なツールとなる。

-- スロークエリログの有効化
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;  -- 1秒以上のクエリを記録
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

-- インデックスを使わないクエリも記録する場合
SET GLOBAL log_queries_not_using_indexes = 'ON';

蓄積されたスロークエリログは mysqldumpslow コマンドで集計・分析できる。

# 実行時間の合計が長い順にトップ10を表示
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

# 実行回数が多い順にトップ10を表示
mysqldumpslow -s c -t 10 /var/log/mysql/slow.log

long_query_time の初期値は 10 秒だが、Web アプリケーションの運用では 1 秒以下に設定するのが一般的だ。閾値が高すぎると問題のあるクエリを見逃してしまう。

ヘルスチェックの実装

アプリケーションやロードバランサーから MySQL の死活監視を行うには、単純な接続確認だけでは不十分な場合がある。実際にクエリが実行できるかどうかまで確認するのが望ましい。

-- 最もシンプルなヘルスチェック
SELECT 1;

-- 書き込み可能かどうかも含めた確認
SELECT @@read_only;
-- 0 ならば書き込み可能、1 ならばリードオンリー

ロードバランサーの背後にソースとレプリカを配置する構成では、ヘルスチェックの粒度を使い分けることが重要になる。

書き込み用エンドポイントでは read_only = 0 の確認まで含め、読み取り用エンドポイントではレプリケーション遅延の閾値チェックも加えるといった設計が典型的。

レプリカに対するヘルスチェックでは、レプリケーションの遅延が許容範囲内かどうかも確認項目に加えるべきだ。Seconds_Behind_Source が一定値を超えたレプリカをロードバランサーから切り離す仕組みを構築しておくと、古いデータを読み取るリスクを軽減できる。

監視ツールとの連携

手動での確認には限界があるため、実際の運用では監視ツールと連携して自動化するのが一般的だ。

ツール	特徴
Prometheus + mysqld_exporter	メトリクスの収集と可視化に強い
Percona Monitoring and Management	MySQL に特化した総合監視
Zabbix	汎用的な監視基盤

これらのツールは MySQL のステータス変数や performance_schema の情報を定期的に収集し、グラフ化やアラート通知を自動で行ってくれる。特に Prometheus と Grafana の組み合わせは、MySQL の各種メトリクスをダッシュボードで一覧表示できるため、トレンドの変化を視覚的に把握しやすい。

定期的に確認すべき指標のまとめ

日常の監視で最低限チェックしておくべき項目を整理しておく。

接続数（Threads_connected）が max_connections に対して余裕があるか

スロークエリ数（Slow_queries）が急増していないか

InnoDB バッファプールヒット率が 99% 以上を維持しているか

レプリケーション遅延（Seconds_Behind_Source）が許容範囲内か

ディスク使用量が逼迫していないか（データディレクトリとログ領域）

監視は「何を見るか」だけでなく「異常値をどう定義するか」も重要だ。正常時のベースラインを把握したうえで閾値を設定し、逸脱した際にアラートが発報される仕組みを整えることが、安定運用の第一歩となる。