Sun. Dec 4th, 2022

Cuándo usar Tablas Temporales en lugar de CON

¡Uno de los mayores asesinos de rendimiento para las consultas es usar CON en lugar de CREAR TABLA TEMPERATURA en situaciones en las que realmente no debería! Después de aclarar que debemos Filtrar lo antes posible en la primera parte de esta serie introductoria a la optimización de SQL, continuemos con cuándo usar o evitar CON.(Foto del autor) Las declaraciones CON también se denominan Expresión de tabla común (CTE). Ayudan a despejar las consultas y las hacen más legibles porque sacan las subconsultas de su contexto y les asignan un nombre. Es decir, SELECCIONE a, b, c
DESDE (SELECCIONE x, y, z DESDE…) se convierte en CON mi_CTE AS (SELECCIONE x, y, z DESDE…) SELECCIONE a, b, c
FROM my_CTEmy_CTE parece una tabla porque está detrás de FROM, pero es no una mesa. Es más como instrucciones en vivo para crear una tabla de resultados sobre la marcha en tiempo de ejecución cada vez que se llama. Eso es salvaje, ¿verdad? CTE no memorizar los resultados de cualquier ejecución anterior! Así que si haces cosas como esta… CON a COMO (…),a1 COMO (SELECCIONE aggr_1 DESDE a),a2 COMO (SELECCIONE aggr_2 DESDE a)
SELECCIONE… DESDE a1 IZQUIERDA ÚNASE a2… entonces necesita cambiar esta consulta tan pronto como termine de leer este artículo, porque pone mucha carga innecesaria en su motor de consultas y ranuras de cálculo al calcular a ¡dos veces! Entonces, ¿qué debemos hacer? a debería ser una tabla temporal en su lugar, porque memorizan sus resultados, al menos durante la ejecución de la consulta. La consulta anterior debería verse así: CREAR TABLA TEMPORAL a COMO (…) CON a1 COMO (SELECCIONE aggr_1 DE a),a2 COMO (SELECCIONE aggr_2 DESDE a)
SELECCIONA… DESDE a1 IZQUIERDA ÚNETE a2Calculamos a solo una vez y utilícelo para las dos agregaciones diferentes en a1 y a2. No es tan diferente del ejemplo anterior, ¿verdad? Pero funcionará mejor porque guardamos el segundo cálculo de a.Y no necesita preocuparse por crear la tabla en un conjunto de datos específico o por eliminar la tabla; BigQuery se encargará de ello y desaparecerá una vez que termine de ejecutarse su instrucción SQL. He visto consultas en las que se hizo referencia a un CTE más de 5 veces. Refactorizar eso en una tabla temporal ayudó bastante, por decir lo menos. Para demostrar que ayudó, podemos probar un par de ejecuciones: tener ambas consultas listas, optimizadas y no optimizadas desactivar el almacenamiento en caché mantener la carga de trabajo total razonable al reducir la cantidad de datos consultados ejecutar ambas consultas alrededor de 5 veces, más o menos al mismo tiempo y compare la media de su tiempo de tragamonedas promedio Además de los cambios que se muestran arriba, es posible que se encuentre con escenarios en los que desee mezclar CTE con tablas temporales. Si realmente solo necesita ejecutar un CTE una vez, será un poco más rápido que ejecutarlo y luego almacenarlo temporalmente. Entonces, si podemos omitir el paso de almacenamiento temporal, deberíamos hacerlo. Entonces, ¿cómo mezclamos CTE y tablas temporales? Puede pensar en CREAR TABLA TEMPORAL como la operación más fundamental. Para usarlos juntos, simplemente contendrá definiciones CTE, porque solo hacen que las subconsultas sean más legibles, pero son esencialmente lo mismo que una subconsulta: CREAR TABLA TEMPORAL a AS (CON x AS (.. .),
y como (…) SELECCIONE… DESDE x IZQUIERDA ÚNASE y ENCENDIDO…)
SELECCIONE… DESDE a… Esta consulta usará CTE x (como se define en la definición de a) para crear la tabla temporal a. Para resumir: use CTE para ordenar sus declaraciones SQL y hacerlas más legibles. Pero no haga referencia a un CTE más de una vez porque el motor de consulta volverá a calcular los resultados cada vez. Para ese caso, use tablas temporales en su lugar: agregarán un paso de almacenamiento adicional al costo de procesamiento, pero eso (+ leer de la tabla temporal) es probablemente más barato que volver a calcular toda la consulta nuevamente. No olvide combinar esta mejor práctica con ¡Filtrar lo antes posible! ¡Feliz refactorización!