2010-02-15 12 views
7

Esto podría ser un poco como preguntar cuánto tiempo una longitud de cadena es, pero las estadísticas son:¿Cuánto tiempo lleva construir un índice usando ALTER TABLE en MySQL?

  • Intel de doble núcleo 4 GB de RAM
  • tabla con 8million filas, ~ 20 columnas, en su mayoría varchars con un AUTO_INCREMENT ID principal
  • La consulta es: ALTER TABLE my_table ADD INDEX my_index (my_column);
  • my_column es varchar (200)
  • almacenamiento es MyISAM

orden de magnitud, debería ser de 1 minuto, 10 minutos, 100 minutos?

Gracias

Editar: OK tardó 2 horas 37 minutos, en comparación con 0 horas 33 mins en una máquina spec menor, con esencialmente idénticas montajes. No tengo idea de por qué tomó tanto tiempo. La única posibilidad es que la prod machine HD esté llena al 85%, con 100GB gratis. Debería ser suficiente, pero supongo que depende de cómo se distribuya ese espacio libre.

+0

¿Cuánto tiempo lleva en un entorno de prueba?La carga del servidor sería lo único que no podrías tener en cuenta, pero no pude ver que llevara más de un minuto. –

+0

ahora estoy corriendo en un entorno de desarrollo ahora. Me esperaba unos 5 minutos. 30 minutos después, nada hecho aún. Además en la parte superior, mysqld parece muy inactivo, mientras que en dev estoy viendo el 60% + de la CPU –

+0

Compruebe si se ha agotado el espacio en disco, en particular en el directorio temporal de MySQL. – nos

Respuesta

5

Si solo está agregando el índice único, debería tomar aproximadamente 10 minutos. Sin embargo, tomará 100 minutos o más si no tiene ese archivo de índice en la memoria.

Su 200 varchar con 8 millones de filas tendrá un máximo de 1,6 GB, pero con toda la sobrecarga de indexación tomará alrededor de 2-3 GB. Pero tomará menos si la mayoría de las filas tienen menos de 200 caracteres. (Es posible que desee hacer una selección de sum(length(my_column)) para ver cuánto espacio se necesita).

Quiere editar el archivo /etc/mysql/my.cnf. Juega con estas configuraciones;

myisam_sort_buffer_size = 100M 
sort_buffer_size = 100M 

Buena suerte.

+0

Hola, gracias por eso. Hice esto antes con ~ 4 mm filas y se completó bastante rápido, así que sí, con 8 mm tal vez, probablemente he empujado el índice en el disco. –

1

Además, si alguna vez necesita crear múltiples índices, es mejor crear todos los índices en una sola llamada en lugar de individualmente ... Razón: básicamente parece volver a escribir todas las páginas de índice para incluir su nuevo índice con lo que sea De lo contrario, tenía. Descubrí esto en el pasado con una tabla de más de 2 o más y tuve que crear alrededor de 15 índices sobre ella. Construyendo todo individualmente mantenido incrementalmente creciendo en el tiempo entre cada índice. Luego, intentar todo de una vez fue un poco más de aproximadamente 3 índices individuales, ya que compilaba todo por registro y escribía todo a la vez en lugar de tener que seguir reconstruyendo páginas.

0

En mi base de datos de prueba MusicBrainz, mesa track construye una PRIMARY KEY y tres índices secundarios en 25 minutos:

CREATE TABLE `track` (
    `id` int(11) NOT NULL, 
    `artist` int(11) NOT NULL, 
    `name` varchar(255) NOT NULL, 
    `gid` char(36) NOT NULL, 
    `length` int(11) DEFAULT '0', 
    `year` int(11) DEFAULT '0', 
    `modpending` int(11) DEFAULT '0', 
    PRIMARY KEY (`id`), 
    KEY `gid` (`gid`), 
    KEY `artist` (`artist`), 
    KEY `name` (`name`) 
) DEFAULT CHARSET=utf8 

la tabla tiene 9001870 registros.

La máquina es Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz con 2Gb RAM, Fedora Core 12, MySQL 5.1.42.

@@myisam_sort_buffer_size es 256M.

+0

hmm, no parece tener myisam_sort_buffer_size o sort_buffer_size especificados en mi my.cnf ... –

+0

bien, así que está completo en mi entorno de prueba, que tiene una especificación menor (3 gb, CPU más lenta y más lenta) en 33 minutos. Prod todavía está revuelto. Desearía que hubiera una actualización de estado o algo ... –

+0

@Richard: si no está especificado, entonces tiene el valor predeterminado ('8M'). Puede verificarlo emitiendo 'SELECT @@ myisam_sort_buffer_size'. Este valor es demasiado bajo, deberías aumentarlo (especialmente si tienes '3 Gb' de' RAM'). Esta memoria solo se usa (y asigna) al crear o reparar los índices, por lo que está bien aumentarla. '@@ sort_buffer_size' no afecta la velocidad de creación del índice, solo afecta las consultas. – Quassnoi

Cuestiones relacionadas