SQLの性能問題は、どこでも発生しやすいものです。

SQLを改修したら、SQLが遅くなったというクレームがあり、通常数時間で終わるバッチ処理が、１日たっても終わらないといったことがかつてありました。

SQLの性能問題が発生した場合は、データベースのパフォーマンス統計やSQL文の実行計画、ER図を見せてもらったり、状況についてヒアリングを行うのですが、よくあるパターンはだいだい決まっています。

なお、以下のパターンは一例です。

(1) レコードによる問題

①そもそもレコード件数が非常に大きい

過去のデータを削除せず、10億件もある巨大なテーブルになっていることが多々あります。

②開発環境で処理時間を計測した場合のレコード数が圧倒的に少ない

本番環境のレコード数では想定以上の時間がかかってしまう。

③特定の列のデータに極端な偏りがある

WHERE句の条件で指定する列のデータに極端な偏りがある場合、探索量が非常に大きくなり、性能劣化となる場合があります。

(2) SQLによる問題

①テーブル間のリレーションが多対多になっている

distinct句やgroup by句を多用することで、性能劣化につながる場合があります。

②WHERE句の絞りこみの条件が不足している

不要なデータも検索してしまい、性能劣化となる場合があります。

③インラインビューを多数使用している。

ヒント句でSQL文の挙動を制御している場合、インラインビュー内ではヒント句が有効にならないため、想定した挙動にならないケースがあります。

④ビューを多用している

複雑な条件をもつビューを多用している場合、ビューを検索する度に、ビューを定義するSQL文が毎実行されるため、性能劣化となる場合があります。

(3) データベース環境による問題

①統計情報が正しくない

適切なデータへのアクセスが行われず性能劣化となる場合があります

②インデックスが不足している、またはインデックスが不適切

インデックスが使用されず、テーブルの全件検索となり、大幅な性能劣化となる場合があります。また、適当でないインデックスが使用された場合、インデックスの探索量が非常に大きくなり、性能劣化となる場合があります。

こういうときに限って、メモリ不足とかディスクの性能不足とかの問題が露呈するので油断ならないのですが、SQL文の改修をするか、テーブルやインデックスの見直し、統計情報の再取得などで、大抵の性能問題は解決します。

SQL文の修正はできないし、データベースの構造はいじりたくないので、インフラだけで解決してほしい、と言われることもあります。

その場合は、こちらでは対応はできないので、メモリのチューニングぐらいしかできないですね、と煙に巻くことにしています。SQLの性能問題が発生した場合の参考にどうぞ。

■ コンピュータ・ユニオン ソフトウェアセクション機関紙 ACCSESS 2022年4月 No.414 より