
アプリのチューニングをする上での優先度は下記になります。
- テーブル構造
- SQL
- メモリ
- ディスクI/O
- OS
上に行くほど、チューニング効果は高いと言われています。
テーブル構造のチューニング
最も効果が高いチューニング手法と言われています。
多くの場合は、ポイントは「テーブルに入っているデータの件数増加」になります。テーブルのデータ件数が多いと、それだけ「検索処理」や「集計処理」に時間がかかってしまいます。
対策
- テーブルを分割して件数を減らせないか検討する。
- 集計結果を別テーブルに格納しておく。
対策することでの影響
テーフル構造の変更を行うと、どうしてもアプリ内のSQLの見直しを行わなければなりません。その後のテストも必要になるので、テーブル構造の見直し自体があまり現実的な手法ではないかもしれません。
SQLのチューニング
SQLチューニングも、それなりに効果が高いチューニング手法になります。
テーブル構造のチューニングに比べると、コストもかからず効果も高いので、かなり一般的に取り入れられている手法になります。
前提条件
まずは、SQLの内部処理の仕組みを理解しましょう。
内部処理に仕組みについては、下記の記事で詳しく解説しています。
SQLチューニングの手順
SQLの内部処理の理解が終わったら、具体的にSQLチューニングを実施していきます。
手順は下記の流れになります。
- ボトルネックとなっているSQLの特定
- アプリで問題となっているSQLが発行されている機能の特定
- SQLチューニングの実施
ボトルネックとなっているSQLの特定
まずは、「どのSQLがボトルネックとなっているか」特定します。特に性能的に問題のないSQLに実施しても意味はないですからね。
おそらく、実際に開発をされた方であれば、この特定はすぐにできるでしょう。
アプリで問題となっているSQLが発行されている機能の特定
次に、そのSQLがアプリ内のどの機能から呼ばれているか確認します。
SQLチューニングの実施
最後に、「SQLのチューニング」を実施します。
主にやることは下記です。
- インデックス(索引)の作成
- SQLの修正
- ヒント句の利用
- バインド変数の利用
インデックス(索引)の作成
インデックスを作成するポイントについては下記の記事でも解説しています。
SQLの修正
ヒント句の利用
ヒント句に関しては、下記の記事で詳しく解説しています。
バインド変数の利用
メモリ、ディスクI/O、OSのチューニング
ミドルウェアやハードウェアレベルで、チューニングできる部分がないか検討します。
DBのチューニングに比べると、コストはかかりませんが、効果が薄かったりインフラのスキルが必要だったりしますので、現場ではあまり活用はされていない印象です。
下記の記事でもハードウェアの性能検討については少し触れています。
まとめ
アプリのパフォーマンスが悪かったりして、チューニングをしたいと考えておられる場合は、できるだけ、効果が高く、短納期の「SQLチューニング」を優先的に選択されることをお勧めします。
もし、スキルがあったり、運用保守をしていてお時間があられるという方の場合は、OS、メモリ、ディスクI/O等のハードウェアのチューニングも検討されてもよいかもしれません。
「テーブル構造のチューニング」は正直、あまり現実的な選択肢ではないです。
この記事へのコメントはありません。