執筆者
M.T.
SQLのコストとは
SQLコストについて以下にまとめてみます。
データベース管理システム(DBMS)がSQL文を実行する場合に必要となるリソース量を見積りした値です。
このコストは、CPU使用量、メモリ使用量、ディスクI/Oなどに基づいて算出されます。
・CPU使用量
処理に必要な計算リソース
・メモリ使用量
データの一時保存に使用
・ディスクI/O
データの読み書き操作
コストの目的
DBMSのオプティマイザがSQLの実行計画を決定する際に利用されます。
オプティマイザは、複数の実行計画の中から最もコストの低いものを選択し、SQLを実行することでSQLのパフォーマンスを最適化しています。
・複数の実行計画を評価
・コストを比較
・最適な計画を選択
実行計画とコスト
実行計画とは、SQLがどのように実行されるかを示す手順書だとされており、実行計画には各操作にかかるコストがパーセンテージなどで表示されます。
このコストを確認することで、パフォーマンスのボトルネックとなっている処理を特定できます。
➤実行計画を確認することで、どの処理が重いのかが一目でわかります。
コストとチューニング
SQLのパフォーマンスが悪い場合は、コストを参考にチューニングを行います。
1.非効率なSQLの特定
パフォーマンスの悪いSQLを見つけます。
2.実行計画の確認
SQLの実行計画を確認し、コストの高い処理を特定します。
3.改善
インデックスの追加やSQL文の書き換えなどにより、コストの高い処理を改善します。
コストの注意点
コストはあくまで見積もりであり、実際の実行時間とは異なる場合があります。
統計情報が古い場合は、実行計画が適切に作成されずコストも正確でなくなる可能性が生じます。
・見積もりと実際の差
コストは推定値であり、実行時間とは必ずしも一致しません。
・統計情報の重要性
古い統計情報は不正確な実行計画とコストにつながります。
SQLの実行コスト
SQLのパフォーマンス改善
業務でSQLのパフォーマンス改善に取り組む機会があり、はじめて「SQLの実行コスト」というものを真剣に意識するようになりました。
今までもSQLは普通に書いていましたし、インデックスの存在も知識としては理解していたつもりでした。
ただ正直なところ、「どれくらい効果があるのか」「どんなふうに使われるのか」といった実感はほとんどありませんでした。
実行計画を見て、やっと腑に落ちた
今回のタスクでは、EXPLAIN を使ってクエリの実行計画を確認しながら、実際にSQLの調整を行いました。
その過程で、インデックスを貼るだけでクエリの実行コストが劇的に下がるということを身をもって体験しました。
実行計画を見てみると、
・インデックスがあると、アクセス方法(スキャンの仕方)が変わる
・インデックスがないと、フルテーブルスキャンになる
といったことがはっきりと分かり、「ああ、こういうことだったのか」とようやく腑に落ちました。
今まで「インデックスって大事らしい」くらいの理解だったのが、今回の経験で実感を持てた感じです。
SQLの実行コストを学んで
JOINの構造って奥深い
特に興味深かったのが JOINの構造です。
これまでは INNER JOIN や LEFT JOIN を「とりあえずこう書けば動くでしょ」くらいで使っていましたが実際には、
・テーブルの参照順序
どのテーブルから読むか
・結合方法
ネステッドループ、ハッシュ結合 など
・インデックスの効果
インデックスが効いているかどうか
といった要素によって、クエリのコストに大きな差が出ることを学びました。
一見シンプルなJOINでも、インデックスがあるかないかで、まったく別物になることもあるんですね。
パフォーマンスと可読性のバランス
とはいえ、SQLは「速ければ正義」というものでもありません。
実際の現場では 可読性や保守性も非常に重要です。
なので、
常にパフォーマンス最優先で書くべきかというと、そうとも限りません。
それでも、
少なくとも「このSQL、もしかしたらコストが高いかも?」という視点を持っておくだけで、パフォーマンスのトラブルを未然に防げることがあると思います。
◆パフォーマンス
・実行速度の最適化
・コストの削減
◆可読性・保守性
・理解しやすいコード
・メンテナンスのしやすさ
今後の意識
今回の経験を通して、これからは単に「正しく書ける」だけではなく、なるべく軽くメンテしやすいSQLを書くことも意識していきたいと思いました。
ちょっとした学びかもしれませんが、自分にとっては大きな気づきだったので、備忘録的に残しておきます。
