その他の関連規範

本記事では、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 時間を大幅に短縮できます。