「PMからWebアプリケーションのDBが遅くなっていると言われました。パフォーマンスチューニングとして何を始めますか？」と面接で聞かれた時にどう答えますか？ありがちなのが、いきなり「INDEXを追加します」「実行計画を見ます」と答えてしまうことです。しかし、最初から解決策に入るのはベストではありません。 こう答えるのが良いでしょう。 まずは、本当にDBが原因なのかも含めて、どこで遅くなっているのかを測定して切り分けます。 最初に、どの画面やAPIが遅いのか、いつから遅いのか、常に遅いのか特定の時間帯だけなのかを確認します。また、その前後でデプロイ、設定変更、トラフィックやデータ量の増加など、何か変化がなかったかも確認します。 あわせて、p95/p99 latency、traffic、error rate、アプリケーションやDBのCPU、Memory、Disk I/O、Connection数などのメトリクスを見て、問題が発生している条件を把握します。 また、トレースやアプリケーション・インフラのメトリクスから、リクエスト全体のどこに時間がかかっているのかを確認します。DBなのか、外部APIなのか、アプリケーション内部の処理なのか、Connection Poolの待ち時間やNetworkなのかを切り分けます。 その結果、DBがボトルネックだと分かった場合は、slow query logやクエリ統計を確認します。 実行時間だけではなく、実行回数、I/O、Lock waitなども見て、システム全体への影響が大きいクエリから優先的に調べます。1回の実行時間は短くても大量に発行されている場合は、N+1などアプリケーション側の問題も疑います。 対象のクエリが特定できたら実行計画を確認して、フルスキャンが発生していないか、想定したINDEXが使われているか、読み取っている行数が多すぎないかなどを確認します。 そのうえで、必要に応じてクエリの書き換えやINDEXの追加、N+1の解消、TransactionやLockの改善などを行います。 できるだけ本番に近いデータ量や代表的なトラフィックパターンをステージ環境や負荷試験で再現し、同じ遅延が発生するか、変更によってどの程度改善するかを確認します。 特にINDEX追加やクエリ変更のように本番への影響があり得る変更は、書き込み性能やLock、デプロイ時の負荷などの副作用も確認します。本番投入のリスクが高そうであれば、段階的なリリースやロールバック方法も事前に考えます。 改善後は、最初に測ったものと同じ指標でもう一度計測して、本当に改善したか、別のボトルネックを作っていないかを確認します。 なので、 「測る → 切り分ける → 問題を絞り込む → 原因を分析する → 改善する → 安全に検証する → 再計測する」 という順番で進めます。 最初からINDEXやキャッシュなどの解決策を決め打ちするのではなく、最初の観測と切り分けを特に重視します。