SQLのパフォーマンスチューニングについて

COLUMN コラム

実は今まで「動けばいい」程度に考えながら実装していたSQL。

最近携わっている案件でそういうわけにもいかなくなってきた。

そもそも今所属している案件がそこそこ多量なデータを扱っているのだが、

積み上げ式にレコードが増えていくデータ構造になっているので、いずれパンクすることは必須なわけで。。

なので実装追加、修正時に触るSQLに対してかなり過敏にパフォーマンスを意識する必要が出てきたなと思う。

その中でやって良かったことなのだが、

例えば100万レコードあるテーブルAをinner joinにかけた以下のようなSQLではパフォーマンスが明らかに劣化する。

select
*
tableX x
inner join tableA a
on x.col = a.col
where
a.col2 > ‘2022/12/31’;

なのでこの場合、where句の条件でgrepした副問合わせを用いて使用すべきである。

with filtered_A as {
select * from tableA where col2 > ‘2022/12/31’
}
select
*
from tableX x
inner join filtered_A fA
on x.col = fA.col;

こうすることで不必要なデータにアクセスすることなく、必要なデータセットのみをjoinしているのでパフォーマンスは良くなる。

※withで切った副問合わせを再利用するケースが無ければ、メインのSQL内で副問して参照するべきかも。どちらが良いかはいつか確認したい。

これについては絶対やるべき。

本番相当環境で問題なく実行できても、本番環境DBで動かすと全く動かないケースが存在するからだ。

（※実際自分も、本番データの10分の1ほどのデータ環境で実施したうえで速度調整、修正を行ったにもかかわらず、リリース時にシステム停止を引き起こした経験があり今でも苦い思い出である。。）

実際に発行するSQLの先頭に「explain analyze」を付与して実行計画を取得、確認をし

修正前とのcostの差、execution Timeを比較することで明らかなパフォーマンス劣化を引き起こしていないかを確認する。