なぜ自動インクリメントは、挿入された行数を超えてジャンプするのですか？

auto_incrementストアドプロシージャを使用して一括挿入を実行した後、BidsテーブルのbidIDに記録されている値に見られるこの奇妙な動作に非常に混乱しています。

INSERT INTO Bids (itemID, buyerID, bidPrice)
 SELECT itemID, rand_id(sellerID, user_last_id), FLOOR((1 + RAND())*askPrice)
 FROM Items
 WHERE closing BETWEEN NOW() AND NOW() + INTERVAL 1 WEEK ORDER BY RAND() LIMIT total_rows;

たとえばauto_increment、開始時にbidID値が101であり、100行挿入した場合、終了値は201ではなく213になります。ただし、挿入された行のbidIDは、最大201まで順次実行されます。

以下を確認して、

SHOW VARIABLES LIKE 'auto_inc%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| auto_increment_increment | 1     |
| auto_increment_offset    | 1     |
+--------------------------+-------+

なぜそれが起こっているのか私にはわかりません。何がauto increment値のジャンプを引き起こしているのでしょうか？

これは珍しいことではなく、いくつかの原因があります。クエリランナーがカウンターリソースとの競合の問題を減らし、影響を受けるテーブルが同時に更新される場合の効率が向上するように最適化されていることが原因である場合があります。明示的にロールバックされた（またはエラーが発生したために暗黙的にロールバックされた）トランザクションが原因である場合があります。

auto_increment列（またはIDENTITYMSSQL、および概念が通っている他の名前）からの唯一の保証は、各値が一意であり、以前の値よりも小さくなることはないことです。したがって、順序付けの値に依存することはできますが、依存することはできません。ギャップがないように。

列の値にギャップがないようにする必要がある場合は、ビジネスロジックの別のレイヤーまたはトリガーを介してDBで値を自分で管理する必要があります（ただし、トリガーの潜在的なパフォーマンスの問題に注意してください）。自分でロールする場合は、DBエンジンがギャップを許可することで回避する、同時実行性/ロールバック/削除後のクリーンアップ/その他の問題に対処する必要があります）。