Oracleの実行計画が書き換わる条件として、「新たなデータ参照用のSQL文の実行が増える」というものは存在するか？

Question

いつも助けていただきありがとうございます。

表題の件について、
Oralce Databese12cを利用しているシステムにおいて、
システムを委託しているベンダーより

現在の検索処理に最適化されている実行計画が、新たな「検索」が増加することにより、
実行計画が変化する可能性があり、その結果、既存の処理の検索効率が悪化する可能性がある。

という指摘を受けております。(詳細は割愛させていただきます…)
※新たな「検索」とは、WHERE句が異なる新たなSELECT文が増えるという意味です。

書き込みが増えることにより、実行計画が書き換わることがあるのは理解できるのですが、
本当に新たな検索が増えるだけで既存の実行計画は書き換わるのでしょうか？

==========追記==========

いろいろと割愛しすぎてわかりにくくなり申し訳ございません。

下記3画面が存在するWebサイトにおいて、

画面①：記事の一覧を取得し表示(SELECT * FROM interviews;)
画面②：タグで絞り込んだ記事の一覧を取得し表示(SELECT * FROM interviews LEFT OUTER JOIN tags ON ...)
画面③：ユーザの一覧を取得し表示(SELECT * FROM users;)

新規画面として「未回答の記事一覧を取得(SELECT * FROM interview WHERE kaitou = false)」する画面を作った場合、
この新規画面のSQLにより、①～③の画面でデータ取得用の実行計画に影響はあるのでしょうか？

Answer 1

新たな「検索」が増加する

これが検索条件の追加という事なら、当然実行計画は変わる可能性はありますね。
検索項目を追加できる仕組みのEUCは良く見かけますが、そういった類なんでしょうか？

もしそうなら、動的に変更される検索用テーブルなどを用いた設計でなければ、性能に影響は出るでしょうね。

追記

新規画面として「未回答の記事一覧を取得(SELECT * FROM interview WHERE kaitou = false)」する画面を作った場合、この新規画面のSQLにより、①～③の画面でデータ取得用の実行計画に影響はあるのでしょうか？

新規の画面で、今までになかった抽出条件のSQLが発生しても、従来の画面で発行しているSQLに影響はありません。
新規画面のSQLに合わせて、チューニングの為にインデックスを追加したりすると従来の画面でのSQLの実行計画に影響が出る場合はあります。

---

開発を依頼した場合の見積もりの内容について疑問を持たれているように見受けられます。
新規で開発を依頼した画面のチューニングを施すでしょうから、そのチューニングが他の画面に影響が無いかどうか調査し、結果的に既存の機能の改修が発生する事はありますよ。

Comments

[teruq]

ご回答有り難うございます。
「新たな検索」が非常に曖昧でしたね。申し訳ございません。

新たな「検索」とは、WHERE句が異なる新たなSELECT文が増えるという意味で使っておりました。

質問に追記させていただきましたので、合わせてご確認いただけますと幸いです。

[teruq]

なるほど、、、単純にSQLを追加するだけではない可能性があるということですね。
頂いた内容をベースに色々質問してみようと思います！ありがとうございました！

Answer 2

パフォーマンス絡みの質問はできるだけ具体的な内容の方が適切な回答が付き易いです。

本当に新たな検索が増えるだけで既存の実行計画は書き換わるのでしょうか？

新たな検索が増えるだけ、ってのはわかりませんが、原因がわからないけどいつの間にか実行計画が変わった、ってのはあり得ます。データの追加・変更・削除があるテーブルにはきちんと統計情報を取得していないと実行計画が適切ではなくなってしまうことがあります。

Comments

[teruq]

ご回答有り難うございます。
「新たな検索」が非常に曖昧でしたね。申し訳ございません。

新たな「検索」とは、WHERE句が異なる新たなSELECT文が増えるという意味で使っておりました。

データの追加・変更・削除が原因でオプティマイザが実行計画を書き換えるのは良いのですが、
新たな検索(SELECT文)が増えただけで実行計画が書き換わるのかが知りたかったのです。

質問に追記させていただきましたので、合わせてご確認いただけますと幸いです。

[Orlofsky]

>①～③の画面でデータ取得用の実行計画に影響はあるのでしょうか？

実行計画に影響はないです。ですが、実行計画が変わらないことを保証するものではありません。
将来なくなる機能ですが、DBMS_OUTLNパッケージhttps://docs.oracle.com/cd/E82638_01/arpls/DBMS_OUTLN.html#GUID-9ECBE2FC-FA2A-4A39-AA4A-395E6C4EDA71 を使うことも考えられます。通常はWebのレスポンス時間やバッチの実行時間を記録して、データ量が増えていないのに処理時間が増えていないかチェックしたり、必要に応じてAWRやstatspack のスナップショットを取得する機能も作り込むことがあります。
提示されたSELECT文ではORDER BYさえないので実用に耐えられないのでは？
差し支えない限り、create table, create index, join している文の全部も提示されたほうが良いです。