database - ¿Qué ocurre cuando auto_increment en la columna de enteros alcanza max_value en las bases de datos?

auto-increment integer-overflow

Question

Estoy implementando una aplicación de base de datos y usaré tanto JavaDB como MySQL como base de datos. Tengo una columna de ID en mis tablas que tiene un número entero como tipo y utilizo las bases de datos auto_increment-function para el valor.

Pero, ¿qué sucede cuando recibo más de 2 (o 4) mil millones de publicaciones y el número entero no es suficiente? ¿El número entero se desborda y continúa o es una excepción lanzada que puedo manejar?

Sí, podría cambiar siempre como tipo de datos, pero ¿cómo puedo verificar cuándo es necesario? Y creo que hay un problema con obtener las funciones last_inserted_id () si uso long como tipo de datos para la columna ID.

Answer 1

Comentario de Jim Martin de §3.6.9. "Uso de AUTO_INCREMENT" de la documentación de MySQL:

En caso de que haya alguna pregunta, el campo AUTO_INCREMENT / NO ENVUELVE /. Una vez que llega al límite para el tamaño del campo, INSERT genera un error. (Según Jeremy Cole)

Una prueba rápida con MySQL 5.1.45 da como resultado un error de:

ERROR 1467 (HY000): Error al leer el valor de incremento automático del motor de almacenamiento

Puede probar ese error al insertar y tomar las medidas apropiadas.

Answer 2

Las respuestas aquí indican lo que sucede, pero solo una respuesta dice cómo detectar el problema (y luego solo después de que ocurrió el error). En general, es útil poder detectar estas cosas antes de que se conviertan en un problema de producción, así que escribí una consulta para detectar cuándo está a punto de ocurrir un desbordamiento:

SELECT
  c.TABLE_CATALOG,
  c.TABLE_SCHEMA,
  c.TABLE_NAME,
  c.COLUMN_NAME
FROM information_schema.COLUMNS AS c
JOIN information_schema.TABLES AS t USING (TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME)
WHERE c.EXTRA LIKE ''%auto_increment%''
  AND t.AUTO_INCREMENT / CASE c.DATA_TYPE
      WHEN ''TINYINT'' THEN IF(c.COLUMN_TYPE LIKE ''% UNSIGNED'', 255, 127)
      WHEN ''SMALLINT'' THEN IF(c.COLUMN_TYPE LIKE ''% UNSIGNED'', 65535, 32767)
      WHEN ''MEDIUMINT'' THEN IF(c.COLUMN_TYPE LIKE ''% UNSIGNED'', 16777215, 8388607)
      WHEN ''INT'' THEN IF(c.COLUMN_TYPE LIKE ''% UNSIGNED'', 4294967295, 2147483647)
      WHEN ''BIGINT'' THEN IF(c.COLUMN_TYPE LIKE ''% UNSIGNED'', ''18446744073709551615'', 9223372036854775807) # need to quote because column type defaults to unsigned.
      ELSE 0
    END > .9; # 10% buffer

Espero que esto ayude a alguien en alguna parte.

Answer 3

Me gustaría compartir una experiencia personal que acabo de tener sobre esto. Usando Nagios + Check_MK + NDOUtils. NDOUtils almacena todos los controles en una tabla llamada nagios_servicechecks. La clave principal es un auto_increment int signed. ¿Qué sucede con MySQL cuando este límite está alineado? Bueno, en mi caso, MySQL elimina todos los registros, pero el último. La mesa ahora está casi vacía. Cada vez que se inserta un nuevo registro, se borra el anterior. No sé por qué sucede esto, pero el hecho es que perdí todos mis registros. IDOUtils, utilizado con Icinga (no Nagios), solucionó este problema cambiando int por un bigint. No generó un error.

Answer 4

Para MySQL 5.6, 3.6.9 Usando AUTO_INCREMENT en dice:

Utilice el tipo de datos entero más pequeño para la columna AUTO_INCREMENT que sea lo suficientemente grande como para contener el valor máximo de secuencia que necesitará. Cuando la columna alcanza el límite superior del tipo de datos, el próximo intento de generar un número de secuencia falla.

Answer 5

Sabrá cuándo se va a desbordar mirando la identificación más grande. Debes cambiarlo bien antes de que una excepción llegue a ser lanzada.

De hecho, para empezar, debe diseñar con un tipo de datos lo suficientemente grande. El rendimiento de su base de datos no va a sufrir, incluso si usa una identificación de 64 bits desde el principio.

Answer 6

Solo para calmar los nervios, considera esto:

Supongamos que tiene una base de datos que inserta un nuevo valor cada vez que un usuario ejecuta algún tipo de transacción en su sitio web.

Con un entero de 64 bits como ID, esta es la condición para el desbordamiento: con una población mundial de 6 mil millones, entonces si cada humano en la tierra ejecuta una transacción una vez por segundo todos los días y cada año (sin descanso) tomaría más de 80 años para que su identificación se envuelva.

Es decir, solo Google necesita considerar vagamente este problema ocasionalmente durante un descanso para tomar café.