8
Así que estoy (todavía) pasando por algunas vistas lentas de sql antiguas que se usan para calcular algunos promedios y desviaciones estándar en un conjunto (a veces) grande de datos. Con lo que termino son vistas que unen vistas que unen vistas, etc.Consultas SQL, planes de ejecución y "Paralelismo"
Así que pensé en revisar el plan de ejecución de mi consulta. Y de inmediato sugirió que faltaba un índice, que luego implementé. Pero sigue siendo insoportablemente lento (tan lento que la aplicación VB6 agota los datos;))
Así que al estudiar el plan de ejecución aún más, veo que lo que más cuesta (aproximadamente 8% cada uno en mi caso) Casos de "Paralelismo". Principalmente, "Distribuir flujos" y "Flujos de reparto". ¿Que son estos?
Trabajé en un sistema similar hace unos años con Vistas uniéndose a Vistas y donde el rendimiento finalmente se volvió inaceptable a medida que crecía la cantidad de datos en el sistema. Descubrí que volver a escribir las consultas desde cero para acceder a las tablas base en lugar de las Vistas daba órdenes de mejora de magnitud en el costo de las consultas. Probablemente encontrará si mira los planes a los que se accede repetidamente a las mismas tablas base para hacer diferentes agregaciones. [Ejemplo de ineficiencia que puede surgir] (http://stackoverflow.com/questions/3222542/is-querying-on-views-slower-than-doing-onery/3222905#3222905) –