자동 증분이 삽입 된 행 수보다 많이 증가하는 이유는 무엇입니까?

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_incrementbidID 값이 시작시 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 엔진이 틈새를 허용하여 해결하는 모든 동시성 / 롤백 / 정리 후 삭제 / 기타 문제와 충돌해야합니다.