ユーザーのSQL書き方がOceanBaseデータベース開発規範に従っていない
ユーザーのSQLの書き方は、SQLの実行パフォーマンスに決定的な影響を与えます。使用する際には、できるだけOceanBaseデータベース開発規範の要件に従う必要があります。詳細については、SQL作成制限を参照してください。
コストモデルの欠陥による実行計画の誤選択
OceanBaseデータベースに組み込まれたコストモデルは、サーバー固有のロジックであり、最適な実行計画はこのコストモデルに依存します。そのため、コストモデルに起因する計画選択の誤りが発生した場合、ユーザーは実行計画のバインディングを通じてのみ、「正しい」実行計画を確保することができます。
データベースの物理設計がクエリ性能を低下させる
クエリの性能は、アクセス対象オブジェクトのスキーマ情報など、データベースの物理設計に大きく依存します。例えば、セカンダリインデックスにおいて、必要な投影列がインデックス列に含まれていない場合、メインテーブルへのアクセスには再アクセス（リフレッシュ）メカニズムを使用する必要があり、クエリのコストは大幅に増加します。この場合、ユーザーの投影列をインデックス列に追加し、いわゆる「カバリングインデックス」を構築することで、再アクセスを回避できます。
システム負荷が単一SQLの応答時間に影響を与える
システム全体の負荷は、システム全体のスループットに影響を与えるだけでなく、単一のSQLの応答時間の変化も引き起こします。OceanBaseデータベースのSQLエンジンはキュー方式を採用しており、ユーザーのリクエストに対して利用可能なスレッドがすべて占有されている場合、新しいリクエストはリクエストキューに入れられ、特定のスレッドが現在のリクエストを完了するまで待機します。リクエストのキュー待ち時間は(G)V$OB_SQL_AUDITで確認できます。
クライアントルーティングとサーバー間でルーティングフィードバックロジックエラーが発生する
OBProxyの主な機能の一つは、SQLクエリを適切なサーバーノードにルーティングすることです。具体的には、ユーザーのクエリで弱い整合性読み取り属性が指定されていない場合、Proxyは関連するテーブル（または特定のパーティション）のプライマリノードにルーティングする必要があり、これによりサーバーノード間での再転送を回避します。そうでない場合、Proxyは事前に設定されたルールに基づいて適切なノードに転送します。
Proxyとサーバー間は疎結合方式を採用しているため、Proxy上のキャッシュされたデータの物理的分布情報の更新が遅延する可能性があり、誤ったルーティング選択を引き起こすことがあります。ルーティング情報の変更が発生する可能性のあるシナリオには以下のものがあります：
ネットワーク不安定によりサーバー間でプライマリノードの再選択が行われる
サーバーのオン/オフ、ローリングコンパクションなどによりプライマリノードの再選択が行われる
ロードバランシングによりプライマリノードの再選択が行われる
SQL Auditや実行計画キャッシュで多数のリモート実行が検出された場合、上記のシナリオと一致するかどうか検討する必要があります。クライアントとサーバー間にはルーティングフィードバックロジックが存在し、エラーが発生するとクライアントはデータの物理的分布情報を自動的に更新し、その後のルーティング選択も正常に戻ります。