OceanBaseデータベースV4.0以前のバージョンでは、オプティマイザーが2段階アーキテクチャを採用しているため、分散計画において接続アルゴリズムが誤って選択されることが多く、その結果、スローSQLが発生することがあります。
問題1：オプティマイザーアーキテクチャの欠陥による接続アルゴリズムの誤選択
原因：
OceanBaseオプティマイザーの2段階アーキテクチャは、分散計画の生成時に以下の問題を引き起こす可能性があります：
- 接続アルゴリズムの誤選択：より効率的なHash Joinではなく、Nested Loops JoinまたはMerge Joinを優先的に選択します。
現象：
- クエリ実行計画にNested Loops JoinまたはMerge Joinが表示されます。
- 分散シナリオにおいてデータ量が非常に大きいため、このようなアルゴリズムのパフォーマンスは低下し、SQLの実行が遅くなります。
解決方法：
DBAは手動でオプティマイザーにHash Joinアルゴリズムを選択させる必要があり、これにより一般的にこのようなスローSQL問題を効果的に解決できます。
問題2：統計情報の不正確さによる誤判断
原因：
基表の統計情報（行数など）の推定が著しく過小であるため、オプティマイザーが誤った判断を下します：
- Nested Loopsが最適な選択肢だと誤認識：オプティマイザーは、小さなテーブルが大きなテーブルをドライブするNested Loopsが効率的なソリューションだと考えます。
- 実際のドライブテーブルのデータ量が過大：実行時にドライブテーブルのデータ量が推定値を大幅に上回るため、Nested Loops Joinの実行効率が極端に低下します。
現象：
- 実行計画にNested Loops Joinが表示されます。
- ドライブテーブルの実際のデータ量がオプティマイザーの推定値を大幅に上回り、実行時間が著しく増加します。
解決方法：
DBAは以下の措置を講じることができます：
- 他の接続アルゴリズム（例えばHash Join）を手動で指定します。
- 接続順序を調整します（例えば、大きなテーブルをドライブテーブルとして使用する）。