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