Empecemos con definir lo que ignoras:
Según Wikipedia, en un resumen bastante simple y entendible:
Cita: Clave primaria:
En el diseño de bases de datos relacionales, se llama clave primaria a un campo o a una combinación de campos que identifica de forma única a cada fila de una tabla. Una clave primaria comprende de esta manera una columna o conjunto de columnas. No pueden haber dos filas en una tabla que tengan la misma clave primaria.
Una clave primaria debe identificar unívocamente a todas las posibles filas de una tabla y no solo a las filas que se encuentran en un momento determinado. Ejemplos de claves primarias son DNI (asociado a una persona) o ISBN (asociado a un libro). Las guias telefónicas y diccionarios no pueden usar nombres o palabras o números del sistema decimal de Dewey como claves candidatas, porque identifican unívocamente números de teléfono o palabras.
Una clave primaria es un caso especial de clave única. La mayor diferencia es que para claves únicas, no se impone automáticamente la restricción implícita NOT NULL, mientras que para claves primarias, sí. Así, los valores en columnas de clave única pueden o no ser NULL. Otra diferencia es que las claves primarias deben definirse por medio de otra sintaxis.
A esto se debe agregar que:
a) Un campo AUTO_INCREMENT en MySQL
es automáticamente definido como PRIMARY KEY.
b) Por definición, una PRIMARY KEY (PK) crea en forma automática un
índice agrupado (cluster), que se utiliza para mantener el
ordenamiento físico de los registros. Por esa razón también es único (un conjunto de datos no puede tener dos ordenamientos físicos diferentes en el disco, ¿o como ordenarías una biblioteca de dos formas al mismo tiempo?)
Respecto a tu problema, hace un tiempo se planteó este mismo asunto y sintéticamente lo que le comenté al forista era:
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 resulta ineficiente y solamente resulta en tiempo de PC consumido.
3. Renumerar un campo autoincremental, genera un nuevo ordenamiento FISICO de los datos, con la consiguiente sobrecarga del microprocesador, porque tiene que reescribir físicamente la tabla otra 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 puede generar inconsistencia de datos entre registros de tablas relacionadas.
5. No se recomienza 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 incremental? ¿para qué perder tiempo en
renumerar?, ¿para que quede más lindo? .
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?
Creo que deberías olvidarte del asunto.