Почему автоматическое увеличение скачков больше, чем количество вставленных строк?

Меня очень беспокоит это странное поведение, которое я вижу в auto_incrementзначении, записанном в bidID таблицы Bids после выполнения массовой вставки с использованием хранимой процедуры:

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 строк, конечное значение становится 213 вместо 201. Однако, идентификаторы bidID этих вставленных строк последовательно работают максимум до 201.

Проверив следующее,

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

Я понятия не имею, почему это происходит. Что может быть причиной скачка auto incrementзначения?

Это не является необычным, и есть несколько причин. Иногда это происходит из-за оптимизаций, выполняемых обработчиком запросов, чтобы уменьшить проблемы конкуренции с ресурсом счетчика, повышая эффективность при одновременном обновлении уязвимой таблицы. Иногда это происходит из-за транзакций, которые были откатаны явным образом (или откатаны неявно из-за ошибки).

Единственная гарантия от auto_incrementстолбца (или IDENTITYв MSSQL, и других именах, которые использует концепция) состоит в том, что каждое значение будет уникальным и никогда не будет меньше предыдущего: так что вы можете положиться на значения для упорядочения, но вы не можете полагаться на у них не должно быть пробелов.

Если вам нужно, чтобы значения столбца вообще не имели пропусков, вам нужно будет управлять значениями самостоятельно, либо на другом уровне бизнес-логики, либо в БД с помощью триггера (хотя будьте осторожны с потенциальными проблемами производительности с триггерами), конечно вы делаете свой собственный, вам придется столкнуться со всеми проблемами параллелизма / отката / очистки после удаления / другими проблемами, с которыми работают механизмы БД, допуская пропуски).