SQLのレスポンスが遅い原因3つ

 私はこれまで業務アプリSEとして多くの性能問題を対応してきました。その大半は下記の3つの原因でした。

1.統計情報が古い、最新でない

一番よくあるパターンです。とりあえず統計情報を取得してみるだけでも解決することがあります。システムを開発するときは、統計情報の取得のタイミングもぜひ設計することをおすすめします。

統計情報が最新でない場合、ORACLEオプティマイザは最適な実行計画を立てることが出来ません。そのため、非効率なアクセスパスで、データを取得することにより、レスポンスが悪化することがあります。

2.SQLが最適ではない

通常、プログラムというと、javaやVBといったプログラミング言語になります。SQLはこれらの言語とは決定的に違う言語になります。SQLは特にアルゴリズムを意識することなく簡単に、かつかなり自由度の高いコーディングが出来ます。

そのため、その自由度の高さがゆえに、非効率なアルゴリズムで実行されてしまうSQLもたくさんあります。このあたりを全てORALCEオプティマイザが吸収して常に最適な実行計画を立ててくれれば良いのですが、そう上手くもいきません。よってSQLを記述する者がアーキテクチャを理解し、アルゴリズムを意識してSQLを記述する必要があります。

このサイトでも、「SQLチューニングするときの心得」や「SELECT文のSQLチューニング方法まとめ」でチューニング方法を紹介しています。他にも多数あります。参考にしてみてください。

参考書で学ぶも良しです。

・プロとしてのOracleアーキテクチャ入門

プロとしてのOracleアーキテクチャ入門第2版 図解と実例解説で学ぶ、データベースの仕組み [ 渡部亮太 ]

・プロとしてのSQLチューニング入門

【中古】 プロとしてのSQLチューニング入門 Oracle現場主義 /福田武志【著】 【中古】afb

3.検証が十分ではない

良くある話ですが、検証では、本番機に劣るスペックや少量のデータを使って検証していることが多々見られます。特にデータ量が少ない場合と本番データのように大量のデータを扱う場合では、パフォーマンスの結果が全く異なるケースも珍しくありません。やはり検証段階から、本番相当のデータ(量や中身)を準備して性能検証を行いましょう。

とはいえ、十分に検証できないことも多々あります。そのような場合には、事前にヒントを入れるなどして、実行計画を狙い通りのものにするなど対応も可能です。

このサイトでも、「SQLチューニングするときの心得」や「SELECT文のSQLチューニング方法まとめ」でチューニング方法を紹介しています。他にも多数あります。参考にしてみてください。