本記事では、OceanBaseにおけるデータベースDMLステートメントの記述規範について説明します。
INSERTステートメントでは、具体的なフィールド名を指定する必要があります。
INSERT VALUES(......)の形式では書かないでください。挿入するcolumn_nameを指定してください。本番環境では、
ignore index、straight_join、SQL_no_cacheの使用を禁止します。プログラムからSQLステートメントに渡すパラメータ値の型は、データベース内のフィールドの型と可能な限り一致させてください。そうでない場合、暗黙的な型変換が発生します。
パーティションテーブルのDMLステートメントにおけるWHERE条件では、パーティションキーの使用を推奨します。
ステートメントでは、パーティションまたはサブパーティション名の周囲に括弧を付ける必要があります。例:
obclient> SELECT * FROM tbl1_l2 PARTITION(p2,p3); +------+------+ | col1 | col2 | +------+------+ | 8 | 8 | | 9 | 9 | +------+------+ 2 rows in setステートメントによるデータの変更効果は、トランザクションをコミットしたときにのみ永続的に有効になります。単一のDMLステートメントもトランザクションになり得ます。
条件を指定せずに更新する場合、レコード数が数十万または数百万に達すると、大規模なトランザクションが発生し、失敗する可能性があります。
UPDATEでは、変更する行数を適切に制御し、トランザクションが大きくなりすぎないように注意してください。
DELETEステートメントのWHERE条件句はオプションです。WHERE条件句を指定しない場合、テーブル全体が削除されます。レコード数が数十万または数百万に達すると、大規模なトランザクションが発生し、パフォーマンスに影響を与える可能性があります。WHERE条件を指定してバッチ処理で削除するか、TRUNCATE TABLEステートメントを使用することを推奨します。
業務キャッシュテーブルのシナリオでは、例えば頻繁なINSERTやDELETE、データのライフサイクルが短いシナリオなどにおいて、HINTを追加してクエリを指定する必要があります。
OceanBaseデータベースはこのようなシナリオに対してrow purgeの最適化を施しており、DELETEノードを回収してクエリのパフォーマンスを向上させることができます。業務シナリオの多様性を考慮し、row purgeで回収できないケースによるパフォーマンス低下を防ぐため、業務側でHINTを指定してクエリを実行することを推奨します。
削除または更新のSQLは最適化が必要で、基本的なルールは粒度をできるだけ細かくすること(100件以下)、およびWHERE条件には検索を容易にするためにインデックスを設定することを推奨します。
TRUNCATE TABLEはDELETEよりも高速で、システムおよびトランザクションログリソースの消費も少ないですが、TRUNCATEはトランザクションを伴わないため、事故を引き起こす可能性があります。そのため、開発コードでこのステートメントを使用する際は、慎重に操作し、誤りがないことを確認することを推奨します。
説明
TRUNCATE TABLEは、WHERE句を持たないDELETEステートメントと機能的に同じです。