第28回: スロークエリログの活用 — 「なんとなく遅い」を計測ベースで解決する

(Updated: )
1 min read

章: 第6章: セキュリティと本番運用

「重いクエリがある気がする」という勘に頼っていませんか？

本番でパフォーマンス問題が発生したとき、「たぶんこのクエリが重いはず」という勘で対応しても、インデックスを追加したのに改善しない・別のクエリが原因だったという事態になりがちです。

スロークエリログを有効にすると、実際に時間がかかっているクエリを記録し、改善対象を優先順位付きで把握できます。 勘ではなく証拠ベースで最適化を進めるための出発点です。

スロークエリログの主要設定と使い分け

設定項目 用途 推奨値（目安）
slow_query_log ログ有効・無効の切り替え ON
long_query_time 記録する閾値（秒） 最初は 0.5 〜 1.0 秒で開始
slow_query_log_file ログの出力先パス /var/log/mysql/slow.log など
log_queries_not_using_indexes インデックス未使用クエリも記録 ON（開発時）
min_examined_row_limit 調査行数が少ないクエリを除外 状況に応じて設定

チェックポイント: long_query_time は最初は低め（0.5秒程度）に設定して観測を始めてください。閾値を高くしすぎると問題のあるクエリが記録されずに見逃します。ログが増えすぎる場合は徐々に閾値を上げて調整します。また、mysqldumpslow コマンドでログを集計すると改善優先度が見えやすくなります。

実際のコードサンプル


-- 主要設定の確認
SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'long_query_time';

-- 実運用では設定ファイルで有効化

まとめ & 次のステップ

  • スロークエリログを有効にし、実際のボトルネックを計測ベースで特定する
  • long_query_time は低め（0.5〜1秒）から始め、記録量を見ながら調整する
  • 記録されたクエリは EXPLAIN で実行計画を確認し、フルスキャンの有無をチェックする
  • mysqldumpslow -s t slow.log で実行時間の合計が多いクエリから優先的に対応する
  • 改善前後の実行時間を必ず記録し、効果を数値で残す

次回は レプリケーションの基礎 を学びます。読み取り分散と可用性向上のためのPrimary-Replica構成の仕組みを解説します。

Related Articles