Reorganizar Indices Mysql

[sagaru]

Hola compañeros.

Se me está pasando por la cabeza reorganizar el índice primario de una tabla, éste índice se auto incrementa, y con las operaciones de borrado de registros pues va a saltos....

¿Sería recomendable reorganizarlos?

He probado con OPTIMIZE TABLE pero no los reorganiza.

¿Alguna idea?
Estoy pensando en hacer algún script, pero sin tener que mover los datos de una tabla a otra...

Saludos

[gnzsoloyo]

Este problema ya se planteó alguna vez con el post de otro forista, y te lo voy a resumir de esta forma:

1. No es conveniente "reorganizar" un índice autoincremental porque en esencia es una tarea sin funcionalidad, carente de practicidad y consumidora de tiempo de procesos. El renumerar las PK 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.

2. Renumerar un campo autoincremental, reordenando la tabla sobre la base de otros campos, 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.

3. Tampoco es recomendable bajo ninguna circunstancia, renumerar una PK si se usa como FK de otras tablas, porque puede generar inconsistencia de datos entre registros de tablas relacionadas.

4. 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.

5. Finalmente, dos detalles:
- Por un 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?
- Por otro lado, si el problema es que te puedes quedar sin números, entonces redefine el campo como BIGINT UNSIGNED, el que te permite del 0 al 18.446.744.073.709.551.615. ¿O es que esperas usar más IDs que eso?

Yo creo que no te debes preocupar por el tema.

[sagaru]

gnzsoloyo, gracias por tu extensa explicación.

La idea se origino porque tengo una tablita con indice tinyint(3), y por no ver saltos, pero realmente no le veia mucha utilidad, pero por mejorarla ...

[gnzsoloyo]

Una un índice autonumérico en TINYINT es un índice que como mucho te dejará usar de -127 a +128 si es SIGNED, o 0 a 255 si es TINYINT UNSIGNED.
Ese rango de representación es absolutamente inservible para la mayoría de los casos porque solamente te permite un máximo de 127 registros en un caso y 255 en otro. Solamente se justifica en una tabla usada para identificar cantidades limitadas de instancias, como por ejemplo los departamentos de una empresa, las facultades de una universidad o los géneros literarios en una biblioteca (suponiendo que no se clasificaron más de 255).
Para el caso, lo que tienes que establecer ANTES de definir la longitud del ID es cuál es el rango máximo que puede adquirir ese valor, esto es hasta qué valor usarás... Habitualmente es mejor usar el INTEGER, que se extiende hasta 4.294.967.295 en UNSIGNED.

Mi sugerencia es que replantees el problema usando esta página para elegir la longitud: MySQL 5.0 Reference Manual :: 11 Tipos de columna :: 11.2 Tipos numéricos