本記事では、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ステートメントと機能的に同じです。