MySQL の AUTO_INCREMENT がトランザクション失敗時にロールバックしないのはなぜですか?

MySQL の AUTO_INCREMENT の謎: ロールバックしない理由

MySQL の AUTO_INCREMENT フィールドは、InnoDB のトランザクション サポートと組み合わせると、次のような興味深い質問を提示します。 AUTO_INCREMENT 値はトランザクション後も変更されませんかrollback?

設計の理論的根拠を理解する

予想に反して、AUTO_INCREMENT フィールドの非ロールバック動作は意図的なものです。その理由を説明するために、複雑なトランザクション シナリオを考えてみましょう。

シナリオ:

1. プログラム 1 は、自動インクリメントされた主キー ( 557).
2. プログラム 2 は FOO (558) にレコードを挿入し、 BAR (FOO の 558 値を参照する外部キーを持つ)。
3. プログラム 2 はトランザクションをコミットします。
4. プログラム 3 は FOO からレポートを生成し、558 レコードを出力します。
5. プログラム 1 はロールバックします

ジレンマ:

AUTO_INCREMENT フィールドがその値をロールバックすると、次のようになります:

• FOO の 557 値 (主キーをデクリメントするとデータが破壊されます)整合性)?
• BAR の 558 値 (ダングリング外部キー参照)?
• 印刷された 558 レコード (レポートから削除する方法)?

ジレンマの解決

はありませんこのジレンマを一定時間で解決します。ただし、レコードのステータス フラグを使用することで、データの整合性を維持できます。このアプローチでは、次のことが必要です。

• 最初の挿入時にレコードのステータスを「未完了」に設定する。
• トランザクションを開始し、処理が成功した後にステータスを「完了」(または同様のもの) に更新する。
• トランザクションをコミットしてレコードを有効にします。
• トランザクションのイベントで不完全なレコードを保存します。

結論

MySQL の AUTO_INCREMENT フィールドの非ロールバック動作は型破りに見えるかもしれませんが、データの破損を防ぎ、参照整合性を維持するように設計されています。複雑なトランザクション環境で。ステータス フラグを使用する回避策では、トランザクションをロールバックする機能が犠牲になりますが、重要な監査シナリオでのデータの整合性が確保されます。

以上がMySQL の AUTO_INCREMENT がトランザクション失敗時にロールバックしないのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。