Что происходит, когда в двигателе БД не хватает чисел для использования в качестве первичных ключей?

Question

Поскольку БД не используют номера удаленных записей повторно , возможно, не хватит чисел, особенно если вы выбрали не очень большой тип целого числа для этого столбца.
Что будет и как это предотвратить, если это плохо?

// SQL Server, MySQL //

Answer 1

Вы получаете 3+ часа простоя, как Slashdot в их функции комментариев.

Answer 2

Я думаю, что именно произойдет, будет зависеть от того, какой движок базы данных вы используете (могут даже быть различия между INNODB и MyISAM в MySQL). Что бы ни случилось, это не будет красиво.

Вам просто нужно изменить тип столбца на большее целое число.

Answer 3

Большинство систем баз данных имеют числовой тип данных, который может быть шире 32 бит. Если вы ожидаете более 2 ^ 32 записей, вам следует использовать соответствующую ширину ключа.

Answer 4

Для MySQL задокументировано, что:

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

Answer 5

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

Answer 6

В Postgres «последовательный» тип эквивалентен созданию SEQUENCE с параметром NO CYCLE и установке значения по умолчанию для поля nextval. Исчерпание такой последовательности приводит к ошибке:

http://www.postgresql.org/docs/8.3/interactive/sql-createsequence.html

Answer 7

Да, это возможно: если вы разрешите использовать только 2-значные номера, у вас может быть только ID до 99 и т. Д. Вставки потерпят неудачу, как только предел будет достигнут. Выбор подходящего размера - это вопрос здравого смысла.

Answer 8

Как правило, вы получите ошибку. Используйте BIGINT, если вы параноик.

Answer 9

Я пробовал это в SQL 2000 некоторое время назад. После Integer.MaxValue следующим значением идентичности является Integer.MinValue. Затем он продолжает считать, как вы ожидаете. Пока записи, которые раньше существовали в 1,2,3 и т. Д., Исчезли к тому времени, когда они туда попадут, ничего плохого не произойдет. Если он встречается с дубликатом (а поле является первичным ключом), вставка завершается неудачно с нарушением ключа. Я не пробовал столбец идентификации, который не ограничен уникальными значениями. Я предполагаю, что это было бы хорошо с дубликатами.

Answer 10

Oracle не поддерживает автоинкрементные столбцы идентификаторов, и стандартная практика заключается в использовании генератора последовательностей. Последовательность генерирует целые числа до 28 цифр, так что, если у вас закончились эти числа, то ... Я думаю, у вас довольно большая таблица. Но тогда поведение будет зависеть от конфигурации генератора последовательности - либо ошибка, либо возврат к начальному значению, и вы получите нарушение ограничения PK при следующей вставке.