Lo que quiero decir es lo siguiente:
Si crear un índice en una tabla con nfilas lleva ttiempo. La creación de un índice en la misma tabla 1000*ntomará aproximadamente 1000*ttiempo.
Lo que estoy tratando de lograr es estimar el tiempo que lleva crear el índice en la base de datos de producción creando el mismo índice en la base de datos de prueba mucho más pequeña.
La creación de índices es esencialmente una operación de clasificación , por lo que, en el mejor de los casos, tiene una complejidad de crecimiento del orden n log nen promedio (es posible que en algunos casos lo haga mejor y no sea mucho peor).
Si todas sus páginas de datos relevantes se ajustan a la RAM y ya están en la RAM, y el índice también se ajustará, y su DBMS no obliga a escribir las páginas de índice antes de que se complete la creación (por lo que los bloques de índice no se actualizan en el disco varias veces durante la operación), entonces la velocidad de escritura del índice resultante en el disco será más significativa que el tiempo necesario para realizar la clasificación, por lo que es posible que se acerque a una relación lineal entre el número de filas y el tiempo que lleva la creación del índice. ¡pero si asume el peor de los casos, es menos probable que se sorprenda desagradablemente!
Recuerde que a menos que no vaya a detener el acceso a la base de datos de producción durante la operación, cualquier creación de índice competirá por el ancho de banda de E / S y / o bloqueos con otra actividad, por lo que debe intentar tener esto en cuenta si está haciendo sus pruebas de estimación de tiempo en otro sistema incluso si está configurado de forma idéntica.
También vale la pena señalar que si puede dividir los ejes para los índices de los ejes para la tabla, entonces podrá trabajar desde dos discos a la vez (aún limitado a la velocidad del controlador de disco en el medio, si un RAID o similar, pero aún así será más rápido que un disco).
Me doy cuenta de que crear un índice no es completamente una operación de lectura y escritura simultánea, pero sí acelera las cosas considerablemente.
CAVEATS: Yo mismo soy un chico de MSSQL, por lo que no estoy seguro acerca de MySQL, pero tengo que imaginar que el concepto de división de husos no es específico de SQLServer y Oracle (donde he oído hablar de eso también, IIRC ) Simplemente no sabría cómo configurar ese concepto. Pero, en términos de SQLServer, significaría tener un grupo de archivos separado además de PRIMARYcolocar los índices en el otro grupo de archivos, con el otro grupo de archivos asignado a un conjunto de husos no involucrados PRIMARY(la colocación de husillos garantizada frente a los grupos de archivos es otra historia completamente diferente)
Si se hiciera esta pregunta hace unos 6 años, habría dicho enfáticamente que NO, ya que se refería a MySQL 4.x. Sin embargo, MySQL 5.x realiza la creación de índices linealmente hoy. Acabo de tener una experiencia nostálgica al explicar esto en mi respuesta a esa pregunta anterior.
fuente
Depende.
Variable n. ° 1: Si MySQL elige construir los índices sobre la marcha, o esperar hasta que todos los datos estén disponibles, haga una ordenación, etc., para construir el índice. Nota: los índices ÚNICOS (creo) deben construirse sobre la marcha para que se pueda verificar la UNICIDAD. La CLAVE PRIMARIA para InnoDB se almacena con los datos (o podría decirlo al revés), por lo que DEBE construirse aleatoriamente.
Variable n. ° 2: el índice rastrea los datos (por ejemplo, AUTO_INCREMENT o marca de tiempo) versus aleatorio (GUID, MD5), o en algún punto intermedio (número de parte, nombre, id_amigo).
Variable n. ° 3 (si el índice se crea sobre la marcha): el índice puede caber en la memoria caché (key_buffer o innodb_buffer_pool), o puede derramarse en el disco.
Los índices que rastrean los datos son eficientes y prácticamente lineales, independientemente de la respuesta al # 1.
Los identificadores aleatorios son un dolor. Si el índice no cabe en la memoria caché, el tiempo para construirlo será mucho peor que el lineal, independientemente de las otras variables. (No estoy de acuerdo con Rolando en este caso). Una enorme tabla de InnoDB con un GUID para la PK es dolorosamente lenta para INSERTAR en el plan en 100 filas / seg para discos ordinarios; quizás 1000 si tienes SSD. CARGAR DATOS e INSERTOS por lotes no lo llevará más allá de la lentitud del almacenamiento aleatorio.
3.53 a 5.6: no ha cambiado mucho.
Husillos múltiples? El trazado de bandas RAID es mejor en casi cualquier situación que asignar manualmente esto aquí y aquello allí. La división manual conduce a situaciones desequilibradas: una exploración de tabla está atascada en el disco de datos; una operación de solo índice está atascada en el disco de índice; una consulta solitaria golpea primero el disco índice, luego el disco de datos (sin superposición); etc.
fuente