チューニング対象のSQLの見つけ方・「遅い」SQLの目安

質問はずばり、SQLを「遅い」と判断する具体的な処理時間・判断基準は？
です。前提は比較的単純なSELECT文とさせてください。


パフォーマンスチューニングする際などにはSTATSPACK reportをみてとりあえず
1回あたりの処理時間が遅いSQLやStatement Totalの 処理時間が長いSQLを
ターゲットにしていくものだと思います。

しかし極端な話、単に上位といってもトップのSQLの処理時間が1msec以下だったらそもそも
パフォーマンスチューニングは一切必要ないはずです。

逆にTOP10以下でも単純なSQLなのに1秒以上処理時間のかかるものが多数あった場合には
何か問題があるはずと考えチェックしていくべきだと思います。

もちろん、データ数や結合テーブル数・条件の複雑さによって一概には言えないことはわかります。


しかし、大体の目安というものはあるべきかと思います。
私のなんとなくの判断基準は
「軽めのものは0.03秒程度、重めでも0.2秒程度」かなーと思っています。
経験的なものでまったく根拠はありません。経験も大してありません。

なので、もう少し根拠のある数字もしくはもう少し経験のある方のご意見
を伺いたいと思い質問させていただきます。
よろしくお願いします。

No.1 回答者： whiteline507 回答日時： 2009/04/02 01:51

はっきりと申し上げて無いと思いますね。

おっしゃるとおり
データ数や結合テーブル数・条件の複雑さによって一概には言えません。
INSERTであればまだある程度は言えると思いますが、
UPDATEやDELETEもwhere句が入ればインデックスのあるなしやテーブル
削除対象件数などでどうとでも変わってきますし、
ましてやSELECT文であれば中間表、DISKの速さ、フェッチ件数
などでいくらでも変わってきます。
フェッチ件数が10件、結合するテーブルの件数がそれぞれ10万件件、
結合テーブル数が3個、結合方式が内部結合のハッシュジョイン、
orderby,groupbyは無し、DISKのアクセス速度は2msec、
DBキャッシュにはヒットしないこととし、ハードパースも走ることとする。SQL文の長さは200文字程度といった程度の情報があって
やっと±500%くらいのブレでやっと見積もれると思います。
と言っても机上で見積もる方法はなく、それと同じ環境を作って試すだけなのですが。

あと、1msecであればチューニングしなくてもよいというのも間違いです。1msecのSQLが100万回実行されているなら
100秒かかっている1回だけ実行されているSQLよりも優先してチューニングするべきです。
もちろん「1msecより0.1msecでも縮められる場合は」ですが。

データベースを勉強している人はよく陥りがちなのですが、
SQLを速くすることがメインの目的では無いのです。
あくまで誰かが使うアプリケーションを速くすることが目的で
そのためにアプリケーションが内部で発行しているSQLを速く
するのです。0.1msecのSQLが速い遅いを決めるのではなく、
「このアプリケーションのこの処理を何秒で返せるようにする。」
それが目的です。

SQL個々の処理時間の目標を決めるのではなく、
DB全体を見渡してのボトルネックの特定とそのボトルネックを一つ一つ改善していくことが一番のアプリケーション高速化の近道だと思います。

この回答へのお礼

ありがとうございました。

お礼日時：2011/11/06 10:39