Верхний предел для первичного ключа автоинкремента в SQL Server

Это зависит от типа данных. Если вы используете bigint, вы вряд ли когда-нибудь переполнитесь. Даже обычный int дает пару миллиардов строк. Я никогда не переполнялся, поэтому не могу сказать, что произойдет, если вы это сделаете.

Описание типов данных:

BIGINT    Integer data from -2^63 through 2^63 - 1

INT       Integer data from -2^31 through 2^31 - 1

SMALLINT  Integer data from -2^15 through 2^15 - 1

TINYINT   Integer data from 0     through 255

Когда вы достигнете верхнего предела, автоинкремент перейдет к нижнему пределу.

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

Вот пример двух из них:

• int: 2 ^ 31-1 (2 147 483 647)
• bigint: 2 ^ 63-1 (9,223,372,036,854,775,807)

Я действительно достиг предела в работе, на которой работал. Фактическая ошибка:

    Msg 8115, Level 16, State 1, Line 1
    Arithmetic overflow error converting IDENTITY to data type int.
    Arithmetic overflow occurred.

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

1. Если столбец идентификаторов не имеет для вас значения (это не внешний ключ и т. д.), Вы можете просто повторно заполнить базу данных и сбросить столбец идентификаторов.
2. Измените свой столбец личности на большее число. Так, например, если вы переполнили int, измените столбец идентификатора на большой int. Удачи, переполняя это :)

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

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

Пришлось изменить столбец на BIGINT. Для базы данных размером 26 ГБ на несколько медленном сервере это заняло около 30 минут. В архивной версии базы данных (150 ГБ или около того) это заняло немного больше времени.

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

DBCC CHECKIDENT (SomeTable, RESEED, 1)

Это сбрасывает идентификатор на 1 в таблице SomeTable.

Не уверен, что это лучший способ сделать это.