Столкнулся со странностью работы auto_increment в xtradb-таблице. Суть в следующем:

Есть две таблицы:

и


В первой таблице хранится 827 записей. Мне нужно вставить во вторую таблицу по 2 записи на каждую запись в первой.
Для этого выполняю 2 идентичных запроса:

и


Запросы выполняются подряд, в это время к серверу никаких других запросов не производится, он работает, можно сказать, в однопользовательском режиме.

В итоге после первого запроса в таблице attribute_group появляется 827 записей с id от 1 до 827.
После второго запроса также добавляется 827 записей, но их id начинаются не с 828, как ожидалось, а с 1024.

Первой мыслью было то, что такая работа - это какой-то патч для повышения производительности в самой xtradb - слишком уж 1024 похоже на какое-то двоичное выравнивание. Но на поверку оказалось, что в стандартном innodb ситуация такая же.

Никаких сведений в документации по этому поводу не нашел.
В общем-то ситуация некритичная, уникальность id сохраняется, но хотелось бы знать, что это: баг или фича?)


Присоединённый файл ( Кол-во скачиваний: 4 )
 auto_increment.png 26,17 Kb

сходу ничего не нашел. кроме самого факт, что воспроизводится проблема-то.

Я не понял... а какое собсно твоё дело, какой автоинкремент сгенерён? он не для работы, а только для обеспечения целостности и связей.

Не знаю как вам, но мне не очень комфортно работать с системами, логика работы которых мне не ясна. Вот я эту логику и пытаюсь узнать и понять.

ЗЫ: Как я уже сказал, баг не критичен, но это не повод приходить и грубить в топике, в котором вы не знаете что ответить.

Akina, ты знаешь причину "пропусков"?

Добавлено через 35 секунд

спокойно. никто не грубит.

Добавлено через 2 минуты и 6 секунд

зависит от причин этих проявлений.
возможно, это симптомы бага/фичи, из-за которых не стоит использовать конструкцию insert ... select. к примеру.

Очень приблизительно. Пару раз вопрос обсуждался, народ сырцы копал, что-то находил, кто-то нашёл какие-то фантомные транзакции даже. Но дыры в суррогатных ключах мне лично совершенно неинтересны (я считаю, что любой отображающий их код перегружен действием, не имеющим смысла), и я не досмотрел, на чём дело успокоилось.


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


Это не баг. Если тебе нужна нумерация строго по порядку - заведи ещё одно поле и нумеруй его без дырок, расчётно или триггером. А синтетический ключ оставь системе для её нужд.
Или перейди на использование естественного ключа. Но тогда это однозначно будет не автоинкремент.


"Не верю!" (с)

Сразу(в очередной раз) скажу, в MySQL не шарю, но гипотезу таки изложу, ибо скучаю.

InnDB, в отличии от MyISAM, если я не путаю, позволяет конкурентный доступ к таблице. Соответственно должен както обеспечивать возможности одновременной вставки несколькими процессами. Однако, что если таблица имеет автоинкрементное поле? Для двух вставляющих процессов это будет разделяемый ресурс. Если мы будем наращивать счетчик по единичке, на этом ресурсе будут постоянно толкаться две конкурирующие сессии и никакого профита от паралеллелизма мы не увидим. Потому, многие системы наращивают счетчики не на еденичку,  забирают под сессию/*транзакцию*/ сразу некий диапазон, как только диапазон выработался, забирают новый. Это позволяет более эффективно испльзовать разделяемый ресурс. В оракле размер кэша последовательности - настраиваемый параметр.
Думаю, проявление этого, или же чегото сродни, и предстало перед нашими очами.

Это сообщение отредактировал(а) Zloxa - 11.11.2010, 13:21

В соответствии с документацией

Т.е. УНИКАЛЬНЫЙ. И не более.

Можете обрыть всю документацию - но нигде не удастся применительно к нему найти слово ПОСЛЕДОВАТЕЛЬНЫЙ (consecutive, cascade, consistent, sequential, serial и т.п.). И это относится не только к MySQL - то же будет и для любого другого сервера БД.

Akina, у меня создается ощущение что ТС не настаивает на том, что MySQL обязан ему выдать непрерывную последовательность. Ему, мне кажется, лишь интересны причины, обуславливающие ее прерывистость.

Добавлено через 58 секунд
А холивор на тему обеспечения бездырочной нумирации, таки да, уже приелся. Но тут, мне кажется, не тот случай. 

Но если его при этом не устраивает версия "by design" - то есть два пути. Либо рыть самому, либо искать результаты того, кто рыл до него. Первое ему не нравится, кажется, а что до второго... я лично видел такие копания, но где именно - не помню. Да и было это давно, по-моему, ещё аж для 3-й версии... 

Akina, ИМХО, ТС лишь погорячился использовать слово "баг". Меня тоже это малость покоробило, но, видать у меня настрой сегодня несколько добродушный, я на это слово не саггрился. 

Нак бы там ни было, думаю надо таки навести статускво

Не утверждайте, что нашли ошибку

Да, сам факт того, что пропущены ID меня мало волнует. Интересны только причины такого нестандартного поведения.

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

Версия by design меня бы устроила, если бы база так вела себя всегда. Тут же получается, что случай нестандартный, иначе на него уже бы давно обратили внимание.

Этот топик как раз и создан чтобы узнать, рыл ли кто-то ранее и что узнали в результате.


Так и есть 

Это сообщение отредактировал(а) HeliosArt - 11.11.2010, 14:12

не думаю.
большинство разработчиков БД, как уже верно заметил Akina,  озабочено обеспечением уникальности первичного ключа.
Его непрерывностью озабочены лишь пытливые мозги ищущих новичков. Да и то - далеко не всех. 

Я вот с ностальгией вспоминаю те полные наива времена, когда еще на фоксе, в девяностые годы, на производственной практике бился с обеспечением непрерывности нумерации ключа при удалении.


ну хрен сним, заменим слово "транзакция" на "стейтмент"(или как биш оно на руский то переводится) 
что это меняет?


Это сообщение отредактировал(а) Zloxa - 11.11.2010, 14:18

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

Согласно официальной документации по innodb:



Т.е. в документации механизм работы auto_increment описан явно и "каждый раз как угодно как угодно." тут не прокатит.

Причина же пропуска нашлась, и догадка Zloxa оказалась верной, ибо среди кучи текста о последовательности и предсказуемости нашлось следующее:


Только при этом логика разработчиков мне все равно не ясна: если уж AUTO-INC lock висит на таблице до завершения всего statement'а и в ходе запроса новые значения выделяются row-by-row, то почему по завершении не вписать в счетчик последнее использованное значение? Для этого даже файловые операции не понадобятся - он только в памяти хранится. Но это уже не для этого форума вопрос