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