Надежна функция поколения автопервичного ключа Баз данных?

Я хотел бы добавить еще одну вещь, о которой следует помнить при использовании функции auto_inc в MySQL:

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

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

Вот снимок двух таблиц (не обращайте внимания на маленькие идентификаторы):

employees                       former_employees
------------------------        ------------------------
id   |  name  |  ...            id   |  name  |  ...
------------------------        ------------------------
27   | Peter  |  ...            29   | Andrew |  ...
28   | Jacko  |  ...            30   | Dennis |  ...
32   | Paula  |  ...            31   | Lenny  |  ...
                                33   | JoDon  |  ...

Обратите внимание, что бывший_работник последний идентификатор равен 33 и что сотрудников счетчик auto_inc сейчас равен 34 .

Если вы выключите сервер на этом этапе и перезапустите его, сотрудники auto_inc вернутся к 33 !!! Это потому, что MySQL не сохраняет счетчик auto_inc между перезапусками !

Имейте это в виду. С уважением.

PS: Чтобы обойти эту «функцию», вам нужно будет запустить хранимые процедуры, которые смотрят на бывший_employees последний идентификатор и устанавливают его, если он больше.

Примечание (С.Леске): Это относится к таблицам InnoDB, но не к таблицам MyISAM. Не знаю о других движках таблиц.

Что вы имеете в виду под "надежностью"?

Базы данных используют блокировки.

В базе данных нет понятия "одновременно". Ресурсы блокируются, а доступ на запись сериализуется.

О чем вы спрашиваете? Пожалуйста, уточните слово "надежный" в вашем вопросе.

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

Вы спрашиваете, возможно ли получить дублирующий ключ для столбца IDENTITY, который не имеет ограничения уникальности? Да, это возможно (поэтому необходимо выполнить DBCC CHECKIDENT RESEED), хотя вероятность этого мала. Со мной такое случалось в нескольких случаях в SQL Server за последние несколько десятилетий. Единственный способ надежно гарантировать, что любое поле будет уникальным, - использовать ограничение уникальности (или ограничение первичного ключа).

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

Есть одна оговорка: вы можете вставить дублирующиеся значения в столбец, если вы вставите их явно (если СУБД позволяет явно установить значение столбца autoinc, что большинство СУБД и делает). Это может показаться тривиальным, но вы можете создать "бомбу замедленного действия", если вы (случайно) вставите в столбец autoinc явное значение, которое больше, чем текущий идентификатор autoinc.

Это будет работать нормально, пока счетчик autoinc не достигнет значения, которое вы вставили, затем "бум" (т.е. нарушение ограничений).

Это может произойти, например, если вы копируете записи из другой базы данных или восстанавливаете резервную копию. У нас была такая проблема в наших системах, и теперь мы регулярно "пересинхронизируем" счетчики autoinc: После "опасного" обновления, такого как копирование всей БД, мы извлекаем наибольшее используемое значение для каждого столбца autoinc и устанавливаем счетчик autoinc в значение +1.