VillageSQL is a drop-in replacement for MySQL with extensions.
All examples on this page work on VillageSQL. Install Now →
スロークエリログの有効化
サーバーを再起動せずに、実行時に有効にできます。my.cnf または my.ini に追加します。
何が記録されるか
典型的なエントリは次のようになります。Rows_examined / Rows_sent の比率が重要なシグナルです。 MySQL が 1 行を返すために 847,293 行を調べたなら、1 つの結果を見つけるためにテーブルのほぼ全体をスキャンしています。それがインデックスを必要とするクエリです。
インデックスを使わないクエリの記録
オーバーヘッドの小さい別の方法として、実行時間に関係なく、インデックスをまったく使わないクエリだけを記録できます。log_throttle_queries_not_using_indexes と組み合わせて頻度を制限します。
mysqldumpslow によるログの分析
混雑したサーバーでは、スロークエリログは急速に肥大化します。mysqldumpslow は類似のクエリを集約して合計時間で順位付けするため、最初に修正すべきものを簡単に見つけられます。
N と S に置き換えます。
スロークエリを EXPLAIN にかける
コストの高いクエリを特定したら、それらにEXPLAIN を実行して実行計画を確認します。
type: ALL(フルテーブルスキャン)と Extra: Using filesort を探してください。どちらもインデックスで修正できます。MySQL のインデックスの仕組みと MySQL の EXPLAIN の読み方を参照してください。
よくある質問
long_query_time は何に設定すべきですか?
1 秒から始めてください。最悪のクエリに対処したら、中程度の問題を捕捉するために 0.1 に下げます。パフォーマンスが重要なアプリケーションでは、0.05 以下がよく使われます。0 に設定するとすべてのクエリが記録されます。これは特定の操作のプロファイリングには便利ですが、本番環境の監視には向きません。
スロークエリログを有効にするとパフォーマンスに影響しますか?
ごくわずかです。オーバーヘッドは、記録されるクエリごとの少量の I/O です。long_query_time = 1 の混雑した本番サーバーでは、本当に遅いクエリだけが書き込まれるため、一般的なオーバーヘッドは無視できる程度です。すべてのクエリを記録する(long_query_time = 0)と測定可能なオーバーヘッドが生じるため、一時的にのみ使用してください。
ファイルを読む代わりに、SQL からスローログをクエリできますか?
はい。log_output = TABLE を設定していれば、mysql.slow_log テーブルを使えます。performance_schema にスローログのテーブルはありません。
トラブルシューティング
スロークエリログと
mysqldumpslow は、拡張機能を備えた MySQL のドロップイン代替である VillageSQL でもまったく同じように動作します。
関連項目
- MySQL の EXPLAIN の読み方 — 見つけたスロークエリを分析する
- MySQL のインデックスの仕組み — スロークエリの最も一般的な修正
- MySQL のコネクションプーリング — スロークエリログでは捕捉できないもう 1 つの遅延の原因
- MySQL のクエリが遅いのはなぜ? — ログが明らかにしたクエリにどう対処するか
- ORM で MySQL を使う: Django、Rails、Prisma — ORM が生成するものを捕捉する