есть вот такая странная штука

вставляю в таблицу 10 строк из файла



они добавляются.кроме этого там есть поле ID которое и  AUTO_INCREMENT
оно показывает в итоге 10,все верно...


но если добавить еще строки,причем неважно как-или опять LOAD DATA или руками INSERT, то ID=11 не будет ! вообще

нумерация начнется с 12.

вопрос-почему и как это убрать?

Вопрос - ЗАЧЕМ это убирать?
Без вменяемого обоснования, что ИНАЧЕ НЕЛЬЗЯ - твой вопрос лишён смысла.

чтобы "преподаватель"   не задавал вопросов в духе "почему порядок не правильный?"
спросил у двух знакомых прогеров-ниодин не смог помочь)

преподователь сто пудов хотел(хотя....), что бы вы ему объяснили почему так происходит, а не пытались на это повлиять.

Порядок... какой? блин, отправь преподавателя читать маны по тому, для чего существуют суррогатные ключи. Уникальность соблюдена? соблюдена... свободен. Нужен порядок? введи дополнительное поле и заполняй его последовательно. А автоинкрементный ключ оставь базе данных для её собственных нужд.

Добавлено через 1 минуту и 8 секунд

ага... перекопать исходный код сервера БД (если он вообще открытый) и найти, где програмисты допустили эту "фичу"?

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


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

Да? просветишь? применительно к описанному выше однопользовательскому (по факту) режиму и наблюдаемому эффекту... насколько я знаю, такой вещи как резервирование автоинкремента ни одна СУБД не реализует, а другого вменяемого обоснования мне придумать не удалось... или ты о просто видимой разрывности автоинкремента в многосеансной среде?


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

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

еще раз - без тест кейса породолжение темы - пустомельство, я пас.


ТС еще забыл дописать - "мамой клянусь так все и было".



это?:


для кого бага, а для кого вполне предсказуемый результат.

нет, 

Добавлено через 1 минуту
или то же одним запросом, если СУБД позволяет

пример несколько размазанный, если все же имелось ввиду:



или


то последовательность явно будет нарушена при одновременном использовании, а рассматривать данный вариант для одного сеанса не имеет смысла.

Для сеанса - запросто. А для таблицы-то почему бы?

максимальный id=100

сеанс 1:
insert...

сеанс 2:
insert...

сеанс 1:
commit;

сеанс 2:
commit;

в таблице две записи с полем id = 101, если поле id - primary key, то сеанс 2 отваливается по dup_val_on_index - что не правильно организационно.

DimW, твой мозг вызжен версионниками.
На блокировочнике, при read commited второй insert встанет на блокировке до коммита первого.  
Попробовал на M$2к  
Для блокировочников тесткейс малость другой должен быть.
Какой, на вскидку щас не скажу.

хм.. тесткес у меня был такой

сессия 2

теперь я понял почему последние 6 постов наша дикуссия с Akina, была подобна разговору глухого с немым.   
неплохая статья On Transaction Isolation Levels, By Tom Kyte.
что прикольно, описано как уровни изоляции оракла отличаются от остальных СУБД.
Zloxa, спасибо за ценную инфу