システム全体の負荷が急増しリソースが逼迫している状況では、まずオペレーティングシステムの観点から原因を絞り込む必要があります。以下の手順に従って、データベースプロセスが資源争奪の起因となっているかを確認し、適切な対処を行います。
top -bcn1 | head -20上記コマンドの実行により、即時かつ定型出力されたプロセス一覧の中から%CPU値が突出しているものを抽出します。表示結果においてmysqldが上位を占めている場合、以降の対応はデータベースレイヤーに集中させていきます。
外部プロセスの影響排除
リソース消費の主因がデータベースサーバー自体ではない場合は、該当プロセスの動作背景を検証します。定期的なバッチ処理やバックアップジョブ、あるいは設定ミスによる無限ループなどが疑われます。straceやlsofを用いてファイルディスクリプタやシステムコールを追跡し、不要なプロセスであることが確認できれば安全に停止させます。また、マルウェア感染の可能性も除外するようセキュリティログとの照合を実施してください。
データベース内部のボトルネック特定
mysqld がCPUを占有している場合、実行中のステートマシンを可視化することが最優先事項です。従来のコマンドに加え、パフォーマンススキーマテーブルを活用した詳細なフィルタリングが推奨されます。
SELECT
THREAD_ID AS id,
USER,
SUBSTRING_INDEX(HOST, ':', 1) AS client_ip,
CURRENT_SCHEMA,
TIMED_OUT_SECONDS AS runtime_sec,
LAST_EVENT_NAME AS state,
LEFT(SHORT_SQL_TEXT, 60) AS query_snippet
FROM performance_schema.events_statements_summary_by_thread_by_event_name
JOIN performance_schema.threads USING(THREAD_ID)
WHERE COUNT_STAR > 0
ORDER BY AVG_TIMER_WAIT DESC, MAX_TIMER_WAIT DESC
LIMIT 20;このクエリにより、実際に計算コストを消費しているステートメントと累積待機時間を明確に把握できます。状態欄でSending data、Sorting result、Coping to tmp tableといったイベント名が含まれる行は典型的な負荷源です。
実行計画の検証と索引設計の見直し
特定された高負荷クエリに対して、オプティマイザがどのようなパスを選択しているかを確認します。構文構造を変更したり結合条件を見直したりする前に、以下の構文を実行して計画書を表示させます。
EXPLAIN FORMAT=JSON <対象クエリ>;JSON形式で取得した結果より、cost_info.query_costやused_key_partsの項目をチェックします。もしアクセス方法がtable_scan（フルテーブルスキャン）となっており、データ量が見込まれない場合は、複合索引の追加やカラム型の適合性確認が必要です。また、サブクエリの平坦化や集合関数の活用によって、一時テーブルの生成を回避できるか検討します。
パラメータ調整とセッション制御
短期的な混雑緩和として、特定のクライアント接続を解除する方法があります。ただし、トランザクション整合性の観点からKILL QUERY <id>（現在実行中の命令のみ停止）の使用を基本とし、完全に確立済みの接続に対してのみKILL CONNECTION <id>を実行してください。
根本的な対策としては、インメモリオペレーション向けの領域割り当てを現行数値から再評価します。innodb_buffer_pool_sizeは物理RAMの70〜80%付近を目安に設定し、同時にtmp_table_sizeとmax_heap_table_sizeの上限値を揃えることでメモリ内のソート処理を促進します。加えて、アクティブなコネクション数が正規のピーク値を大幅に超えている場合は、アプリケーション側のリトライ機構を見直すと同時に、max_connectionsおよびback_logの適正化を図ります。
観測可能性及び予防的メンテナンス
- PrometheusとGrafana、またはPercona Monitoring and Management (PMM) を導入し、QPS、スレッドキュー状態、バッファプールヒットレート、I/Oウェイトなどのメトリクスを可視化します。
- 遅延クエリログについては閾値を厳格に設定し、自動アーカイブと共に集計ツールへ連携させます。
- 定期的な実行計画のドリフト分析と索引使用頻度レポートを確認することで、新たなボトルネックを未然に封じ込めます。
- ハードウェアリソースの限界点を事前に把握し、垂直スケールではなくレプリケーション構成への移行やパーティショニング検討など、アーキテクチャ段階での見直しサイクルを確立します。