Perché l'incremento automatico salta di oltre il numero di righe inserite?

Sono molto turbato da questo strano comportamento che sto vedendo nel auto_incrementvalore registrato nel bidID di una tabella di offerte dopo aver eseguito l'inserimento di massa utilizzando una procedura memorizzata:

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;

Ad esempio, se il auto_incrementvalore bidID è 101 all'inizio e ho inserito 100 righe, il valore finale diventa 213 anziché 201. Tuttavia, gli bidID di tali righe inserite vengono eseguiti in sequenza fino a un massimo di 201.

Dopo aver verificato quanto segue,

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

Non ho idea del perché stia accadendo. Cosa potrebbe causare il salto nel auto incrementvalore?

Questo non è insolito e ci sono un paio di cause. A volte è dovuto alle ottimizzazioni apportate dal Runner query per ridurre i problemi di contesa con la risorsa contatore, migliorando l'efficienza quando sono presenti aggiornamenti simultanei alla tabella interessata. A volte è dovuto a transazioni che sono state esplicitamente ripristinate (o implicitamente ripristinate a causa di un errore).

L'unica garanzia da una auto_incrementcolonna (o IDENTITYin MSSQL e gli altri nomi che il concetto passa) è che ogni valore sarà unico e mai più piccolo di uno precedente: quindi puoi fare affidamento sui valori per ordinare ma non puoi fare affidamento loro di non avere lacune.

Se hai bisogno che i valori della colonna non abbiano alcuna lacuna, dovrai gestire i valori da solo, in un altro livello di logica aziendale o nel DB tramite un trigger (fai attenzione però ai potenziali problemi di prestazioni con i trigger), ovviamente se fai il tuo dovere dovrai affrontare tutti i problemi di concorrenza / rollback / cleanup-after-delete / altri che i motori DB risolvono consentendo spazi vuoti).