Prácticas recomendadas para diseñar consultas de Amazon Redshift

En esta sección se proporciona una descripción general de las prácticas recomendadas para diseñar consultas. Le recomendamos que siga las prácticas recomendadas de esta sección para lograr un rendimiento y una eficacia óptimos de las consultas.

Evite usar la instrucción SELECT * FROM

Le recomendamos que evite usar la SELECT * FROM declaración. En su lugar, siempre enumere las columnas para su análisis. Esto reduce el tiempo de ejecución de las consultas y los costes de análisis de las consultas de Amazon Redshift Spectrum.

Ejemplo de lo que se debe evitar

select * 
from sales;

Ejemplo de mejores prácticas

select sales_date, sales_amt
from sales;

Identifique los problemas de consulta

Le recomendamos que compruebe la vista STL_ALERT_EVENT_LOG para identificar y corregir los posibles problemas de la consulta.

Obtenga información resumida sobre su consulta

Se recomienda utilizar las vistas SVL_QUERY_SUMMARY y SVL_QUERY_REPORT para obtener información resumida sobre las consultas. Puede utilizar esta información para optimizar las consultas.

Evite las uniones cruzadas

Se recomienda evitar el uso de uniones cruzadas a menos que sea absolutamente necesario. Sin una condición de unión, las uniones cruzadas dan como resultado el producto cartesiano de dos tablas. Las uniones cruzadas suelen ejecutarse como uniones en bucle anidado (el tipo de unión más lento posible).

Ejemplo de lo que se debe evitar

select c.c_name, 
          n.n_name 
from tpch.customer c, 
        tpch.nation n;

Ejemplo de mejores prácticas

select c.c_name, 
           n.n_name 
from tpch.customer c, 
join tpch.nation n
  on n.n_nationkey = c.c_nationkey;

Evite las funciones en los predicados de consulta

Se recomienda evitar el uso de funciones en los predicados de consulta. El uso de funciones en los predicados de consulta puede afectar negativamente al rendimiento, ya que las funciones suelen añadir una sobrecarga de procesamiento adicional a cada fila y ralentizar la ejecución general de la consulta.

Ejemplo de lo que se debe evitar

select sum(o_totalprice)
from tpch.orders
where datepart(year, o_orderdate) = 1992;

Ejemplo de mejores prácticas

select sum(o_totalprice)
from tpch.orders
where o_orderdate between '1992-01-01' and '1992-12-31';

Evita conversiones de reparto innecesarias

Le recomendamos que evite utilizar conversiones de conversión innecesarias en las consultas, ya que la conversión de tipos de datos requiere tiempo y recursos y ralentiza la ejecución de las consultas.

Ejemplo de lo que se debe evitar

select sum(o_totalprice)
from tpch.orders
where o_ordertime::date = '1992-01-01';

Ejemplo de mejores prácticas

select sum(o_totalprice)
from tpch.orders
where o_ordertime between '1992-01-01 00:00:00' and '1992-12-31 23:59:59';

Utilice expresiones CASE para agregaciones complejas

Se recomienda utilizar una expresión CASE para realizar agregaciones complejas en lugar de seleccionarlas varias veces de la misma tabla.

Ejemplo de lo que se debe evitar

select sum(sales_amt) as us_sales
from sales
where country = 'US';

select sum(sales_amt) as ca_sales
from sales
where country = 'CA';

Ejemplo de mejores prácticas

select sum(case when country = 'US' then sales_amt end) as us_sales,
           sum(case when country = 'CA' then sales_amt end) as ca_sales
from sales;

Usa subconsultas

Se recomienda usar subconsultas en los casos en que una tabla de la consulta se use solo para condiciones de predicados y la subconsulta devuelva un número reducido de filas (menos de 200 aproximadamente).

Ejemplo de lo que se debe evitar

Si una subconsulta devuelve menos de 200 filas:

select sum(order_amt) as total_sales
from sales
where region_key IN
        (select region_key
         from regions
         where state = 'CA');

Ejemplo de mejores prácticas

Si una subconsulta devuelve un número mayor o igual a 200 filas:

select sum(o.order_amt) as total_sales
from sales o
join regions r
  on r.region_key = o.region_key
  and r.state = 'CA';

Usa predicados

Le recomendamos que utilice predicados para restringir el conjunto de datos tanto como sea posible. Los predicados se utilizan en SQL para filtrar y restringir los datos que se devuelven en una consulta. Al especificar las condiciones en un predicado, puede especificar qué filas deben incluirse en los resultados de la consulta en función de las condiciones especificadas. Esto le permite recuperar solo los datos que le interesan y mejora la eficacia y precisión de las consultas. Para obtener más información, consulte las condiciones en la documentación de Amazon Redshift.

Agregue predicados para filtrar tablas con uniones

Se recomienda agregar predicados para filtrar las tablas que participan en las uniones, incluso si los predicados aplican los mismos filtros. El uso de predicados para filtrar tablas con uniones en SQL puede mejorar el rendimiento de las consultas al reducir la cantidad de datos que se deben procesar y el tamaño del conjunto de resultados intermedios. Al especificar las condiciones de la operación de unión en la WHERE cláusula, el motor de ejecución de consultas puede eliminar las filas que no coincidan con las condiciones antes de unirlas. Esto da como resultado un conjunto de resultados más pequeño y una ejecución de consultas más rápida.

Ejemplo de lo que se debe evitar

select p.product_name, sum(o.order_amt)
from sales o
join product p
   on r.product_key = o.product_key
where o.order_date > '2022-01-01';

Ejemplo de mejores prácticas

select p.product_name, sum(o.order_amt)
from sales o
join product p
  on p.product_key = o.product_key
  and p.added_date > '2022-01-01'
where o.order_date > '2022-01-01';

Utilice los operadores menos costosos para los predicados

En el predicado, utilice los operadores menos costosos que pueda. Los operadores de condiciones de comparación son preferibles a los operadores LIKE. LIKELos operadores siguen siendo preferibles a los operadores TO o POSIX SIMILARES.

Utilice las claves de clasificación en las cláusulas GROUP BY

Utilice claves de clasificación en la GROUP BY cláusula para que el planificador de consultas pueda utilizar una agregación más eficiente. Una consulta puede ser apta para la agregación monofásica si su GROUP BY lista contiene solo columnas de claves de ordenación, una de las cuales es también la clave de distribución. Las columnas de claves de ordenación de la GROUP BY lista deben incluir la primera clave de ordenación, seguida de otras claves de ordenación que desee utilizar en el orden de las claves de ordenación.

Aproveche las vistas materializadas

Si es posible, reescriba la consulta sustituyendo el código complejo por una vista materializada, lo que mejorará considerablemente el rendimiento de la consulta. Para obtener más información, consulte Creación de vistas materializadas en Amazon Redshift en la documentación de Amazon Redshift.

Tenga cuidado con las columnas de las cláusulas GROUP BY y ORDER BY

Si utilizas ambas GROUP BY ORDER BY cláusulas, asegúrate de colocar las columnas en el mismo orden en ambas GROUP BY ORDER BY cláusulas. GROUP BYrequiere implícitamente que los datos se ordenen. Si ORDER BY la cláusula es diferente, los datos se deben ordenar dos veces.

Ejemplo de lo que se debe evitar

select a, b, c, sum(d)
from a_table
group by b, c, a
order by a, b, c

Ejemplo de mejores prácticas

select a, b, c, sum(d)
from a_table
group by a, b, c
order by a, b, c