
17/06/2011, 07:09
|
 | Moderador criollo | | Fecha de Ingreso: noviembre-2007 Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 17 años, 2 meses Puntos: 2658 | |
Respuesta: Mysql editor local Bueno, lo rápido o lento de una importación así depende de tres factores clave:
1) Cuál es la longitud real del archivo descomprimido.
2) Cuál es la estructura de los índices definidos en las tablas.
3) Cuál es el tamaño real de las tablas.
Para darte un ejemplo, tengo una base que comprimida pesa 180 Mb, pero que descomprimida pesa alrededor de 900 Mb, y una vez cargada ocupa 2.4 Gb en disco... Y en el caso de la importación no importa el tamaño del Zip, sino lo que ocupará en el disco una vez cargada.
Los índices no aparecen en el Backup porque no tiene ningún sentido ponerlos en él, ya que pueden generarse en forma automática a medida que los datos se cuelven a almacenar en las tablas. Por eso los índices son críticos para la recarga y mientras más grandes o más complejos, más se tarda en generarlos.
¿Se enntiende?
El tema es que no importa cuál sea el editor, si el problema está en la estructura de la base, tardará lo mismo.
Si quieres la prueba absoluta, descomprímelo, ve a la consola de sistema e intenta cargarlo con la aplicación de consola (mysql.exe). Ese es el tiempo absoluto, porque no depende de ninguna interface.
__________________ ¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente... "El problema es la interfase silla-teclado." (Gillermo Luque) |