また、Oracleを使用していることを前提としています。また、初心者向けに、プランの説明のWebページを確認することをお勧めします。最適化には多くのことがありますが、それは学ぶことができます。
いくつかのヒントが続きます：
まず、誰かがあなたに最適化を任せるとき、彼らはほとんどの場合、究極のパフォーマンスではなく、許容できるパフォーマンスを探しています。クエリの実行時間を3分から3秒に短縮できる場合は、要求されるまで、汗を流して2秒に短縮しないでください。
次に、クイックチェックを実行して、最適化するクエリが論理的に正しいことを確認します。ばかげているように聞こえますが、実行速度の遅いクエリについてアドバイスを求められた回数はわかりません。たまに間違った答えが返されていることがわかりました。そして、結局のところ、クエリをデバッグすることで、クエリを高速化することもよくありました。
特に、説明プランで「デカルト結合」というフレーズを探してください。そこに表示されている場合は、意図しないデカルト座標の参加を見つけた可能性が非常に高くなります。意図しないデカルト結合の通常のパターンは、FROM句がコンマで区切られたテーブルをリストし、結合条件がWHERE句にあることです。結合条件の1つが欠落していることを除いて、Oracleはデカルト結合を実行する以外に選択肢がありません。テーブルが大きい場合、これはパフォーマンスの低下につながります。
クエリが論理的に正しいExplainプランでデカルト結合を確認することは可能ですが、これを古いバージョンのOracleに関連付けます。
また、未使用の複合インデックスを探します。複合索引の最初の列が照会で使用されていない場合、Oracleは索引を非効率的に使用するか、まったく使用しない可能性があります。例を挙げましょう：
クエリは次のとおりです。
select * from customers
where
State = @State
and ZipCode = @ZipCode
（DBMSはOracleではなかったため、構文が異なり、元の構文を忘れてしまいました）。
インデックスをざっと見ると、列（国、州、郵便番号）がこの順序である顧客のインデックスが明らかになりました。クエリを読み取りに変更しました
select * from customers
where Country = @Country
and State = @State
and ZipCode = @ZipCode
オプティマイザーがインデックスを有効に活用できたため、約6分ではなく約6秒で実行されました。アプリケーションプログラマーに、なぜ国を基準から除外したのかを尋ねたところ、これが彼らの答えでした。彼らは、すべての住所に「USA」に等しい国があることを知っていたので、その基準を除外することでクエリを高速化できると考えました。
残念ながら、データベース検索の最適化は、計算時間をマイクロ秒短縮することと実際には同じではありません。これには、データベース設計、特にインデックス、および少なくともオプティマイザがその仕事を行う方法の概要を理解することが含まれます。
オプティマイザーをアウトスマートにしようとするのではなく、オプティマイザーとのコラボレーションを学ぶと、通常、オプティマイザーからより良い結果が得られます。
最適化のスピードを上げて頑張ってください！