Veamos...
De tanto en tanto surge nuevamente este tema y en general lo que quieren hacer es siempre lo mismo:
renumerar. Hace un tiempo tres foristas preguntaron este asunto y te paso a comentar lo que les dije a ellos:
1. No es conveniente "reorganizar" un índice autoincremental porque en esencia
es una tarea sin funcionalidad, carente de practicidad y consumidora innecesaria de tiempo de proceso.
2. El renumerar las PRIMARY KEY de un campo incremental
no produce ninguna mejora en la optimización de consultas, por lo que hacerlo solamente resulta en tiempo de PC consumido.
3. Renumerar un campo autoincremental,
genera un nuevo ordenamiento FISICO de los datos (una PK genera un índice cluster), con la consiguiente sobrecarga del microprocesador, porque tiene que reescribir físicamente la tabla cada vez y reconstruir el índice completamente.
4.
Tampoco es recomendable bajo ninguna circunstancia renumerar una PK (es el caso en MySQL donde un AUTOINCREMENT es PK por default)
si se usa como FK de otras tablas, porque
generará inconsistencia de datos entre registros de tablas relacionadas.
5.
No se recomienda renumerar si existen datos históricos de otras transacciones, que hacen referencia a otros registros que tenían el mismo número. De hecho, en una tabla de stock, las ID jamás cambian porque el hecho que un producto ya no exista ni se fabrique
no quiere decir que no aparezca en registros más antiguos. Pisar un ID sería lo mismo que
ponerle a un recién nacido el número de documento de un muerto.
6. Por otro lado, ¿qué te importa que tengas espacios de números que ya no usas, en tanto la numeración sea secuencial e incremental? ¿para qué perder tiempo en
renumerar?, ¿para que quede más lindo? . Eso lo puedes hacer perfectamente en la interfase, donde
visualizas la tabla de datos, o bien usando variables de usuario en la consulta (ver
FAQs)
7. SI tu temor es quedarte sin números para usar, un ID generado en un campo numérico UNSIGNED tiene estos rangos:
- TINYINT: 0 a 255.
- SMALLINT: 0 a 65.535.
- MEDIUMINT: a 16.777.215
- INT: 0 a 4.294.967.295.
- BIGINT: 0 a 18.446.744.073.709.551.615
¿Esperas usar más IDs que eso?
Recuerda que las bases de datos no se deben manipular caprichosamente. Son el centro neurálgico de la información de las aplicaciones.
Finalmente, en tu caso el hecho de renumerar los registros no hará que el siguiente número a ingresar sea el siguiente al último que está en la base, porque ese valor no se calcula de esa forma, sino que está definido en la estructura de la tabla... Por lo que para que sea efectivo deberás redefinir la tabla misma, con todos los riesgos que ello implica.