本記事では、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時間を削減できます。