MySQL auto_increment innodb_autoinc_lock_mode = 2, но иногда заполняется последовательно

Question

У меня в настройках файла MySQL my.cnf innodb_autoinc_lock_mode = 2, но, глядя на таблицу, первичный ключ иногда не следует этому правилу. В основном у меня есть:

710
712
714
716
718

... и т.д. что хорошо.

Но в некоторых записях у меня есть:

720
722
723
724
725
726
728
730

и т.д ...

Следует ли всегда следовать увеличению на 2 или это скорее предложение?

У нас есть кластерная среда, поэтому он имеет приращение на 2. Пытаясь избежать возможных столкновений клавиш.

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

ставит innodb_autoinc_lock_mode = 1 плохую идею в кластерной среде?

В поисках наилучшего предложения о том, как добиться нумерации накладных без пропусков.

Answer 1

Вы слишком много просите от AUTO_INCREMENT. Это гарантирует уникальный номер. Период; Полная остановка.

auto_increment_increment больше 1 - это метод, впервые использованный репликацией «Мастер-Мастер» для предотвращения дублирования. Позже различные «кластерные» решения заняли одинаковую позицию. Потому что это работает.

Я заметил случайное нечетное число в вашем списке. Один Мастер делает четные числа, другой делает нечетные числа, но вставляет реже. Любая попытка избежать пробелов значительно замедлит обработку. Для 99,9% пользователей это важнее, чем беспокоиться о пробелах.

Я не читаю лекции. Есть несколько случаев, когда будут возникать пробелы. Очевидно, DELETE оставит пробел. Но они иногда оставляют после себя новые пробелы: INSERT IGNORE, IODKU, REPLACE, ROLLBACK. Точно так же вы не можете полагать, что значения будут монотонно увеличиваться.

innodb_autoinc_lock_mode может помочь в некоторых случаях, но не в других. Он был добавлен, когда разработчики обнаружили несколько более быстрый способ создания ИИ, но опять же за счет предсказуемости значений.

ОК, вам нужны последовательные номера счетов , которые никогда не будут удалены, и т. Д. Лучше всего иметь «сервис» (API), который получает «следующий» номер счета. Представьте себе таблицу с одной строкой в ​​одном столбце. И напишите хранимую процедуру, которая увеличивает это число и возвращает его клиенту. Затем клиент использует этот номер везде, где ему нужен номер счета.

Вы можете сделать номера последовательными в зависимости от времени, когда запрашивается номер счета . Может быть довольно трудно сделать их последовательными, основываясь на том, когда счет вставлен. В качестве «счета-фактуры» вы, вероятно, должны когда-либо удалять их, но вместо этого иметь какой-то «удаленный» флаг для обработки ошибок, отмены и т. Д.