Tengo una función SQL que devuelve una tabla. La tabla se completa a través de 6 oraciones razonablemente complejas.One INSERT with UNIONS o multiple INSERTS?
¿Es mejor unir estas declaraciones UNION así que solo hay 1 inserto o estas se mantienen mejor separadas?
¿O no hace ninguna diferencia en absoluto?
Dentro de una función definida por el usuario, no veo una razón para usar una sobre la otra. Un UNION tiene el potencial de ser más restrictivo que las declaraciones separadas ...
Me gustaría ver los detalles de la función, y su uso, porque es posible que no sea necesaria en absoluto.
Me acaba de UNION ALL ellos - la clave no es un UNION (que podría ser menos eficiente por la deduplicación), sino un UNION ALL.
ahh, the union all, ese es un buen punto –
Lo intentaré, porque solo "UNION" es muy lento, desafortunadamente. 5k filas con 1 columna, el mismo valor necesita 10 segundos. 'UNION ALL' requiere menos de 1 segundo. ¡Gracias por esa gran pista! –
En lugar de pensar por sí mismo cuál es la mejor solución que sugiero como consejo para utilizar una herramienta adecuada.
En el servidor SQL que utiliza el Managment Studio puede evaluar el rendimiento por Display Estimated Execution Plan. De esta forma, puedes ver las diferencias entre tus 2 casos y seleccionar el mejor al observar los resultados.
En realidad, hace la diferencia.
Cuando tiene INSERT s por separado, debe tener cuidado de hacerlo dentro de una transacción, para que tenga un estado constante en todo momento. Pero, dado que están separados, la cantidad de memoria requerida para que el servidor se complete es menor porque cada INSERT tiene su propio conjunto de resultados: cuando la consulta finaliza, el servidor puede realizar otra consulta, etc.
Cuándo tiene todo dentro de una gran consulta unida por UNION ALL, el servidor necesitaría más tablas temporales y más memoria para completar. Pero, de esta manera, tiene algo de una inserción 'masiva', y podría dar como resultado una inserción más rápida.
Personalmente, iría con inserciones separadas dentro de una transacción. A veces, simplemente haciendo algo más simple es mucho más beneficioso en términos de mantenimiento y depuración que una pequeña ganancia de rendimiento (si corresponde, depende del número de filas que realmente se inserten)
puede estar en desacuerdo, pero en este caso no creo que necesite transacciones. no se actualizan datos como resultado de estas declaraciones, solo se presentan a un usuario, de modo que si un registro cambia antes de que todo esté completo, eso no me importa. Gracias por la entrada. –
Ok, esa es una razón más para insertos separados porque las transacciones no se aplican sería aún más rápido ... – veljkoz
Estoy de acuerdo con esto.En mi experiencia, un UNION puede ralentizar innecesariamente un proceso de inserción debido al tiempo (y memoria) que lleva crear la unión en primer lugar. Y a menudo las transacciones aún se pueden envolver en inserciones separadas, incluso cuando sea necesario. Me gustaría ir con las inserciones por separado, si estamos hablando puramente de trabajo de base de datos del lado del servidor. – user158017
Sugeriré insertos separados. Descubrí que el rendimiento de la inserción con Union All es muy pobre en comparación con las inserciones separadas. Traté de insertar alrededor de 3500 registros utilizando ambos enfoques, las declaraciones de inserción por separado fueron 4 veces más rápidas. (Puede variar según el número de columnas en su inserción)
Estoy de acuerdo. Alrededor de 1,000,000 de filas de alrededor de 10 mesas diferentes: insertos separados se completan en 6 segundos, ¡UNION ALL no se completó después de 10 minutos! –
es posible hacer esto en una sola inserción sin las uniones pero es increíblemente desordenado (créanme, he tenido una oportunidad) –