MySQL AUTO_INCREMENT: ロールバックの謎を解明する
MySQL では、InnoDB トランザクションで AUTO_INCREMENT フィールドを利用すると特有の動作が発生します: ロールバックは影響しませんAUTO_INCREMENT 値。この設計選択の背後にある理由を理解することが重要です。
次のシナリオを考えてみましょう:
シナリオ:
- プログラム 1 がトランザクションを開始し、レコードをテーブル FOO に挿入し、AUTO_INCREMENT 値を割り当てます。 557.
- プログラム 2 もトランザクションを開始し、FOO にレコードを挿入し、取得します。 558.
- プログラム 2 は、FOO の 558 値を参照して、テーブル BAR にレコードを挿入します。
- プログラム 2 はトランザクションをコミットします。
- プログラム 3 はレポートを生成しますテーブル FOO に基づいており、値 558 のレコードが含まれます。
- プログラム 1 は最終的にトランザクションをロールバックします。
ロールバックと AUTO_INCREMENT:
データベース システムは通常、AUTO_INCREMENT 値をロールバックしません。影響:
-
データ整合性: ロールバック時に 557 値が減分された場合、557 より大きいキーを持つ他のレコードの値は無効になります。
-
外部キー制約: テーブル BAR 内の 558 への参照は次のようになります。 FOO の 558 レコードが削除された場合、孤立します。
-
レポートの不一致: プログラム 3 によって生成されたレポートは、値 557 のロールバックされたレコードを除外するように修正する必要があります。
回避策と代替案:
AUTO_INCREMENT フィールドはロールバックできませんが、特定の要件に対処する代替ソリューションがあります:
-
不完全なレコード: 監査目的、レコードのステータス フラグを維持することを検討してください。作成時に「不完全」とマークされたレコードは、AUTO_INCREMENT 値に影響を与えることなくロールバックでき、監査証跡が得られます。
これらの回避策を実装するには、データの整合性、パフォーマンス、および特定のビジネス ニーズを慎重に考慮する必要があります。
以上がMySQL AUTO_INCREMENT 値が InnoDB トランザクションでロールバックしないのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。