Каков самый большой идентификационный номер, который автоинкремент может производить в mysql

У меня есть база данных, которая быстро заполняется данными, которые мы говорим о 10-20 тыс. строк в день.

Каков предел идентификатора и автоинкремента? Если ID создается как INTEGER, тогда я могу сделать максимальное значение 2 147 483 647 для неподписанных значений?

Но что, когда автоинкремент идет выше этого? Все это рушится? Что тогда будет решением?

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

Спасибо.

Ответы

Ответ 1

Если вы беспокоитесь о том, что это слишком быстро выходит из-под контроля, я бы поставил PK в качестве НЕПРАВИЛЬНОГО BIGINT. Это дает вам максимальное значение 18446744073709551615, которого должно быть достаточно.

Ответ 2

                    | Min. (inclusive)           | Max. (inclusive)
-----------------------------------------------------------------------------
INT Signed (+|-)    |             -2,147,483,648 |             +2,147,483,647
-----------------------------------------------------------------------------
INT Unsigned (+)    |                          0 |              4,294,967,295
-----------------------------------------------------------------------------
BIGINT Signed (+|-) | -9,223,372,036,854,775,807 | +9,223,372,036,854,775,806
-----------------------------------------------------------------------------
BIGINT Unsigned (+) |                          0 | 18,446,744,073,709,551,615

Справочник по MySQL.

Если у вас есть таблица mysql с идентификатором столбца (INT unsigned), и таблица содержит 4 294 967 295 записей, то вы пытаетесь вставить еще 1 запись, идентификатор новой записи будет автоматически изменен и установлен на максимум, равный "4 294 967 295", таким образом, вы получаете сообщение об ошибке MySQL. Duplicate entry '4294967295' for key 'PRIMARY', у вас будут дублированные идентификаторы, если столбец установлен в качестве первичного ключа.

2 возможных решения:

  1. Простой подход: Расширьте пределы, установив идентификатор BIGINT без знака, как сказал Дэн Армстронг. Хотя это не значит, что это нерушимо! и производительность может пострадать, когда таблица станет действительно большой.
  2. Более сложный подход: используйте разбиение, которое немного сложнее, но дает лучшую производительность и действительно не ограничивает базу данных (единственным ограничением является размер вашего физического жесткого диска). Twitter (и подобные огромные веб-сайты) используют этот подход для своих миллионов твитов (записей) в день!