En un comentario que leíinserción masiva con o sin índice
Así como una nota al margen, a veces es más rápido para soltar los índices de la tabla y volver a crearlos después de la operación de inserción masiva.
¿Es esto verdad? ¿En qué circunstancias?
Al igual que con Joel, repetiré la afirmación de que sí puede ser cierto. Descubrí que la clave para identificar el escenario que mencionó está en la distribución de los datos y en el tamaño del (de los) índice (s) que tiene en la tabla específica.
En una aplicación que solía soportar que hizo una importación masiva regular de 1,8 millones de filas, con 4 índices en la tabla, 1 con 11 columnas y un total de 90 columnas en la tabla. La importación con índices tomó más de 20 horas en completarse. Dejar caer los índices, insertar y volver a crear los índices solo tomó 1 hora y 25 minutos.
Por lo tanto, puede ser de gran ayuda, pero gran parte se reduce a sus datos, los índices y la distribución de los valores de los datos.
Sí, es cierto. Cuando hay índices en la tabla durante una inserción, el servidor tendrá que reordenar/paginar constantemente la tabla para mantener los índices actualizados. Si suelta los índices, puede agregar las filas sin preocuparse por eso y luego crear los índices de una vez cuando los vuelva a crear.
La excepción, por supuesto, es cuando los datos de importación ya está en el orden del índice. De hecho, debo señalar que estoy trabajando en un proyecto en este momento donde se observó este efecto opuesto. Queríamos reducir el tiempo de ejecución de una importación grande (volcado nocturno de un sistema de mainframe). Intentamos eliminar los índices, importar los datos y volver a crearlos. En realidad, aumentó significativamente el tiempo de la importación para completar. Pero, esto no es típico. Simplemente demuestra que siempre debe probar primero para su sistema en particular.
¿Sería una alternativa viable insertar los datos nuevos en una tabla temporal y luego hacer algo como INSERT INTO TABLE x (SELECT * FROM y)? Dependiendo de la base de datos, puede haber alguna optimización del índice involucrada, o tal vez estoy fuera de la marca –
No, porque entonces estás haciendo dos inserciones. Por supuesto, su situación puede variar, pero en general esto no ayudará. –
Genial, solo fue un pensamiento. –
Una cosa que debe tener en cuenta al descartar y volver a crear índices es que solo debe realizarse en procesos automatizados que se ejecutan durante los períodos de bajo volúmen de uso de la base de datos. Mientras se descarta el índice, no se puede usar para otras consultas que otros usuarios puedan estar ejecutando al mismo tiempo. Si haces esto durante las horas de producción, es probable que tus usuarios comiencen a quejarse de tiempos de espera.
Creo que en nuestro caso, una gran parte de esto fue que siempre comenzamos con una tabla en blanco, y los datos masivos venían en orden de agrupación. Por lo tanto, no hay mucho trabajo extra pasando. –
Ah sí, eso sería una buena parte de eso. Siempre comenzamos con una tabla en blanco también, ¡pero los datos de entrada estaban por todos lados! –