SQLチューニングに関するよくある質問

ユーザーSQLの記述がOceanBaseデータベースの開発規範に準拠していない

ユーザーSQLの記述方法は、SQLの実行パフォーマンスに決定的な影響を与えます。使用する際は、できるだけOceanBaseデータベースの開発規範に従うようにしてください。詳細については、SQLの記述制限を参照してください。

コストモデルの欠陥による実行計画の誤選択

OceanBaseデータベースに組み込まれたコストモデルは、サーバーの固有ロジックであり、最適な実行計画はこのコストモデルに依存します。そのため、コストモデルに起因する計画選択の誤りが発生した場合、ユーザーは実行計画のバインドを行うことでのみ、「正しい」実行計画の選択を保証できます。

データベースの物理設計によるクエリパフォーマンスの低下

クエリのパフォーマンスは、アクセス対象のスキーマ情報などを含む、データベースの物理設計に大きく依存します。例えば、セカンダリインデックスについて、必要な投影列がインデックス列に含まれていない場合、メインテーブルへの再アクセス（リターンテーブル）メカニズムを使用する必要があり、クエリのコストが大幅に増加します。この場合、ユーザーの投影列をインデックス列に追加し、いわゆる「カバーインデックス」を構築することで、リターンテーブルへのアクセスを回避できます。

システム負荷が単一SQLの応答時間に影響を与える

システム全体の負荷は、システム全体のスループットに影響を与えるだけでなく、単一SQLの応答時間の変動も引き起こします。OceanBaseデータベースのSQLエンジンはキューモデルを採用しており、ユーザーのリクエストに対して、利用可能なスレッドがすべて占有されている場合、新しいリクエストはリクエストキューに並び、あるスレッドが現在のリクエストを完了するまで待機します。リクエストのキュー待ち時間は(G)V$OB_SQL_AUDITで確認できます。

クライアントルーティングとサーバー間でルーティングフィードバックロジックのエラーが発生する

OBProxyの主要な機能の1つは、SQLクエリを適切なサーバーノードにルーティングすることです。具体的には、ユーザークエリで弱い整合性読み取りプロパティの使用が指定されていない場合、Proxyは関連するテーブル（または特定のパーティション）のリーダーノードにルーティングし、サーバーノードでの2次転送を回避する必要があります。そうでない場合、Proxyは事前に設定されたルールに基づいて適切なノードに転送します。

Proxyとサーバー間は疎結合の方式を採用しているため、Proxy上でキャッシュされたデータの物理配置情報の更新が遅延し、誤ったルート選択を引き起こす可能性があります。ルーティング情報が変更される可能性のあるシナリオは以下の通りです：

• ネットワーク不安定によるサーバー間でのリーダー再選出

• サーバーのオン/オフ、ローテーションマージなどによるリーダー再選出

• ロードバランシングによるリーダー再選出

SQL Auditや実行計画キャッシュで多数のリモート実行が検出された場合、上記のシナリオと一致するかどうか検討する必要があります。クライアントとサーバー間にはルーティングフィードバックロジックがあり、エラーが発生するとクライアントは自動的にデータの物理配置情報を更新し、その後のルート選択も正常に戻ります。