SQLパフォーマンスの「見える化」をプロセス全体に適用する

アプリケーションライフサイクルとSQLパフォーマンス

過去2回にわたって見てきたSQLパフォーマンスチューニングの手法を、今回は、アプリケーションライフサイクル全体のなかでとらえなおしてみましょう。

SQLのパフォーマンス問題の多くは、テスト段階でチェックされるべきものかもしれませんが、実際には、運用段階に入ってから問題が顕在化することもあります。また、開発の初期段階から、設計的にパフォーマンスを発揮できない構造を採用していたり、実装中に、パフォーマンス劣化を引き起こす遠因となるコードが混在してしまうかもしれません。

今回は、アプリケーションライフサイクルの各フェーズで、それぞれどのようなSQLパフォーマンスに対する対処が考えられるのかを見ていこうと思います。

設計変更が引き起こすパフォーマンス問題

データベース設計は、最終的にSQLパフォーマンスにも影響を与えます。前回の記事で紹介したように、VST図で表されるパスが非常に複雑になっていたり、冗長になっている場合には、ひとつの結果セットを取得するために大きなコストを必要とします。SQLの記述方法によってこれらを回避するのにも限界がありますから、データベースの設計をより望ましい形にしておくことが重要になります。

ただし、通常は、適切なデータベース設計を行う努力を払ってから実装に入るでしょう。むしろ問題なのは、その後で、要件の変更やさまざまな状況の変化により、データベース構造が変更されたりテーブルが追加されたりした場合です。このような当初想定していなかった拡張を適切に行わないと、パフォーマンスに影響を与えます。

これには、VST図による分析ももちろんですが、ER/Studioのような既存のデータベースからスキーマ情報を取得して、ER図を表示し、編集できるツールを用いて、現状の理解と修正を行うのが賢明でしょう。

実装段階でのSQLパフォーマンス問題への対処

実装段階では、2つの異なるアプローチが重要です。まず、ひとつひとつのSQLの品質を高めること。これは、例えばDB Optimizerにも付属しているSQLコーディング支援機能（単体製品としてはRapidSQL）などを用いて、SQLのコーディング品質そのものを一定品質に保つことができます。SQLコーディング支援機能とは、開発ツールのコード入力支援に類似しており、SQLをタイプし始めると、入力可能な候補がドロップダウンで表示されたり、エラー箇所を指摘したり、さらには、よりよいSQLコーディングの書き換え候補を表示したりするものです。ツールの支援を得ることで、手作業では気がつかない、ちょっとしたコーディング上のミスなどを改善していくことができます。

もうひとつのアプローチは、開発段階からのチューニングです。高いレスポンスが要求されるようなSQLや実行効率が大きく影響するような頻繁に実行されるようなSQLは、アプリケーションコードの側から顕在化する場合があります。これらのSQLについては、プロトタイプ段階からしっかりパフォーマンスリスクを確認しておくことで、実装方法として果たして適切なのかどうかといった吟味が可能になります。

プロトタイプテストでは、大規模な負荷テストや、複雑なデータを用いたテストを行うことは難しいでしょう。しかし、DB Optimizerの統計情報を利用したり、ロードエディタを用いたテストを行うことで、プロトタイプの妥当性を「見える化」できます。

開発段階では、大掛かりなパフォーマンステストを行うことはできませんが、小さなパフォーマンス問題の芽を未然に摘み取っておくことで、後の段階での対応が楽になっていきます。