Web サイトで自動インクリメントされたユーザー ID を使用する予定です。ユーザーデータは複数のテーブルに分割されるため、トランザクションで自動インクリメントされた値の信頼性はどの程度か、つまり、登録時にトランザクションでいくつかの初期値をテーブルに挿入するときに、自動インクリメンターにすべてのテーブルの ID または 1 つのテーブルに挿入し、別のクエリで挿入された ID を取得し、それを後続の挿入で使用して、ユーザー作成のためだけにデータベースの負荷が高くなるようにする必要がありますか?
2 に答える
何かを挿入しようとするたびに、自動インクリメント フィールドが予約されます。挿入は多かれ少なかれ 2 つのステップで進行します。
1: 次に使用可能な自動インクリメント キーを予約します
2: この予約済みキーを使用して挿入を実行します
現在、トランザクションがロールバックされた場合、決してロールバックできない唯一のものは自動インクリメントの予約であり、その結果、自動インクリメント カラムにギャップが生じます。このため、自動インクリメントがどうなるかを 100% 予測しようとしても、それは不可能です。私が知っている auto_increment に関する他の問題はありません。ほとんどの場合、手動で何かをしようとするよりも、mysql の機能に依存する方が信頼性が高くなります。
同時トランザクションがなく、何もロールバックされないなど、非常に制御された条件下で挿入が行われる場合は、安全である可能性があります。それ以外の場合、答えは使用しているストレージエンジンによって異なる可能性があります。少なくともInnoDBを使用している場合はauto_increment
、番号付けにギャップが生じることを期待する必要があります。
より一般的には、私が知っているすべてのDBには、auto_increment
(または同等の)値にギャップがある可能性があります。そうでない場合、新しい行を挿入するトランザクションは、そのテーブルへの他のすべての挿入をブロックする必要があるためです。これは、最初のトランザクションがまだコミットまたはロールバックされていない場合に次の値がどうなるかを知ることができない場合、2番目の行を挿入できないためです。ギャップを許可する場合は、最初のトランザクションがコミットされると想定し、ロールバックが発生した場合はギャップがありますが、それは問題ではありません。
ユーザー作成操作の負荷が高いことが懸念される場合は、関数をストアドプロシージャとして実装することで、作業をより迅速に行うことができる場合があります。このようにして、クエリごとにアプリケーションにラウンドトリップすることを回避できます。