その他の関連規範

本記事では、OceanBaseデータベースに関するその他の関連規範について説明します。

データエクスポートの規範

dataxでエクスポートした後は、複数の小さなファイルに分割し、それぞれを個別にデータベースにインポートします。各小ファイルのサイズは1GB以内に制御してください。

その他

• 本番環境では、force index、ignore index、straight_join、SQL_no_cache の使用を禁止します。

• BEGIN...END、LOOP...END LOOP、REPEAT...UNTIL...END REPEAT、WHILE...DO...END WHILE などの複合文の使用を禁止します。

  説明

  複雑なロジックはアプリケーション側で処理し、複雑なSQLの作成を避けてください。

• ページ検索において、左端あいまい検索または完全一致検索の使用を厳しく禁じます。

  説明

  SQLにLIKE検索を含める場合は、必ず左からの最長一致を使用してください。

• パーティションテーブルにはパーティションキーが必要です。パーティションキーなしですべてのパーティションをスキャンすることを禁止します。

• 3つ以上のテーブルをJOINすることは推奨されません。

• 複数テーブルを結合するクエリでは、ドライバーテーブルは結果セットが小さいテーブルを選択する必要があります。

• 複数層のサブクエリをネストしたSQL文の記述は推奨されません。テーブルの順序を結合する形式に書き換えることを推奨します。

• INSERT、UPDATE、DELETE、REPLACE ステートメントでの複数テーブル結合操作を禁止します。

• クエリ操作において、カバーインデックスを利用して、再アクセスを回避してください。

• カスタム関数、カスタム型、ストアドプロシージャの使用を減らしてください。

  説明

  ストアドプロシージャは問題の特定が困難で移植性に欠けます。また、パフォーマンスの観点から見ると、ストアドプロシージャのSQLは一般的に複数のテーブルや複雑な条件判断を含むものが多く、これらの文自体がパフォーマンスを大幅に消費し、実行時間が長くなります。これによりシステムの同時実行性能が低下します。ストアドプロシージャ内に算術演算が含まれる場合も、深刻なパフォーマンス問題を引き起こす可能性があります。

• 非論理条件クエリ != <> not の使用を減らします。

• 集計関数の使用を減らします。

• in 操作の使用は避けることを推奨します。in を含むサブクエリは可能な限り join に書き換えてください。どうしても使用する必要がある場合は、in list 内の定数の数を100個以下にしてください。

• ステートメント内で WHERE または LIMIT の使用を推奨します。そうでない場合、テーブル全体がスキャンされます。

• 中間結果セットのサイズを制御します。

  説明

  distinct、order by および group by 句を含むクエリでは、中間結果セットは1万行以内に制限されます。1万行を超える大規模な結果セットのソートやグループ化は、アプリケーション側で実装する必要があります。

• hash サブパーティションの数は、2のべき乗にすることを推奨します。そうでない場合、パーティション間でデータが均等に分散されない可能性があります。

• フルテキスト検索機能の使用は推奨されません。

• イベント EVENT 機能の使用は推奨されません。

• アプリケーション内でOceanBaseデータベースおよびtestデータベースの使用や操作を禁止します。testデータベースの作成、またはtestで始まるデータベースの作成も禁止します。

• OceanBaseデータベースでユーザー定義変数の使用を禁止します。

• データベース内で業務上のリアルタイム統計や集計などの計算操作を行わないでください。必要な場合は、データをエクスポートして他のツールを使用するか、オフラインのバックアップデータベースで実行してください。

• HAVING の使用を避けます。

  HAVING 句は GROUP BY の処理後にフィルタリングを行いますが、WHERE 句は処理中にデータをフィルタリングします。そのため、WHERE 句を使用することで、ソートや I/O 時間を大幅に短縮できます。