Mejora del rendimiento de consultas - Amazon Redshift

Mejora del rendimiento de consultas

A continuación, se describen algunos problemas frecuentes que afectan el rendimiento de las consultas y se detallan instrucciones acerca de cómo diagnosticarlos y resolverlos.

Faltan estadísticas de tablas o están desactualizadas

Si faltan estadísticas de tablas o si estas están desactualizadas, es posible que vea lo siguiente:

  • Un mensaje de advertencia en los resultados del comando EXPLAIN.

  • Un evento de alerta en STL_ALERT_EVENT_LOG que indica que faltan estadísticas. Para obtener más información, consulte Revisión de alertas de consultas.

Para reparar este problema, ejecute el comando ANALYZE.

Bucle anidado

Si hay un bucle anidado, es posible que vea un evento de alerta de bucle anidado en STL_ALERT_EVENT_LOG. También puede identificar este tipo de evento si ejecuta la consulta en Identificación de consultas con bucles anidados. Para obtener más información, consulte Revisión de alertas de consultas.

Para reparar esto, asegúrese de que su consulta no tenga combinaciones cruzadas o elimínelas de ser posible. Las combinaciones cruzadas son combinaciones sin una condición de combinación que dan lugar a un producto cartesiano de dos tablas. Por lo general, se ejecutan como uniones de bucles anidados, que son los tipos de unión posibles más lentos.

Combinación hash

Si hay una combinación hash, es posible que vea lo siguiente:

Para reparar este problema, puede optar por varios métodos:

  • Reescribir la consulta para usar una combinación de fusión de ser posible. Puede hacerlo si especifica cuáles son las columnas de combinación que son claves de distribución y claves de ordenación al mismo tiempo.

  • Si el paso HJOIN en SVL_QUERY_SUMMARY tiene un valor muy elevado en el campo rows en comparación con el valor de rows en el paso final RETURN de la consulta, compruebe si puede volver a escribir la consulta para combinarla en una única columna. Cuando una consulta no se combina en una única columna, como en el caso de una clave principal, aumenta la cantidad de filas involucradas en la combinación.

Filas fantasma o filas sin confirmar

Si hay filas fantasma o filas sin confirmar, es posible que vea un evento de alerta en STL_ALERT_EVENT_LOG que indique que hay demasiadas filas fantasma. Para obtener más información, consulte Revisión de alertas de consultas.

Para reparar este problema, puede optar por varios métodos:

  • Revise la pestaña Loads (Cargas) de la consola de Amazon Redshift para ver si hay operaciones de carga activas en cualquiera de las tablas de consultas. Si ve operaciones de carga activas, espere a que se completen antes de realizar cualquier medida.

  • Si no hay operaciones de carga activas, ejecute el comando VACUUM en las tablas de la consulta para quitar las filas eliminadas.

Filas desordenadas o mal ordenadas

Si hay filas desordenadas o mal ordenadas, es posible que vea un evento de alerta de filtro muy selectivo en STL_ALERT_EVENT_LOG. Para obtener más información, consulte Revisión de alertas de consultas.

También puede controlar si alguna de las tablas de su consulta tiene grandes áreas desordenadas si ejecuta la consulta en Identificación de tablas con sesgo de datos o con filas desordenadas.

Para reparar este problema, puede optar por varios métodos:

  • Ejecute el comando VACUUM en las tablas de la consulta para reordenar las filas.

  • Revise las claves de ordenación en las tablas de consulta para ver si puede hacer alguna mejora. Recuerde comparar el rendimiento de esta consulta con el rendimiento de otras consultas importantes y con el sistema en general antes de implementar cualquier cambio. Para obtener más información, consulte Uso de claves de ordenación.

Distribución de datos poco óptima

Si la distribución de datos no es la óptima, es posible que vea lo siguiente:

  • Aparecerá un evento de alerta de ejecución en serie, difusión o distribución de gran tamaño en STL_ALERT_EVENT_LOG. Para obtener más información, consulte Revisión de alertas de consultas.

  • Los sectores no están procesando aproximadamente la misma cantidad de filas en un paso determinado. Para obtener más información, consulte Uso de la vista SVL_QUERY_REPORT.

  • Los sectores no están tardando aproximadamente el mismo tiempo en un paso determinado. Para obtener más información, consulte Uso de la vista SVL_QUERY_REPORT.

Si ninguna de las opciones anteriores es verdadera, también puede controlar si alguna de las tablas de su consulta tiene un sesgo en sus datos mediante la ejecución de la consulta en Identificación de tablas con sesgo de datos o con filas desordenadas.

Para solucionar este problema, consulte los estilos de distribución de las tablas de la consulta y determine si se puede hacer alguna mejora. Recuerde comparar el rendimiento de esta consulta con el rendimiento de otras consultas importantes y con el sistema en general antes de implementar cualquier cambio. Para obtener más información, consulte Uso de estilos de distribución de datos.

Memoria insuficiente asignada a la consulta

Si la memoria asignada a su consulta es insuficiente, es probable que vea un paso en SVL_QUERY_SUMMARY que tenga un valor "true" en is_diskbased. Para obtener más información, consulte Uso de la vista SVL_QUERY_SUMMARY.

Para reparar este problema, asigne más memoria a la consulta aumentando temporalmente la cantidad de slots que usa la consulta. Workload Management (WLM, Administración de cargas de trabajo) reserva slots en una cola de consultas equivalente al nivel de simultaneidad definido para la cola. Por ejemplo, una cola con un nivel de simultaneidad de 5 tiene 5 slots. La memoria asignada a la cola se asigna en partes iguales a cada slot. Asignar muchos slots a una consulta le proporciona a esa consulta acceso a la memoria de todos esos slots. Para obtener más información acerca de cómo aumentar temporalmente los slots para una consulta, consulte wlm_query_slot_count.

Cláusula WHERE poco óptima

Si su cláusula WHERE genera demasiados exámenes de tablas, es posible que vea un paso SCAN en el segmento con el valor máximo de maxtime en SVL_QUERY_SUMMARY. Para obtener más información, consulte Uso de la vista SVL_QUERY_SUMMARY.

Para reparar este problema, añada una cláusula WHERE a la consulta basada en la columna de ordenación principal de la tabla más grande. Este enfoque ayuda a reducir el tiempo de análisis. Para obtener más información, consulte Prácticas recomendadas de Amazon Redshift para el diseño de tablas.

Predicado poco restrictivo

Si su consulta tiene un predicado poco restrictivo, es posible que vea un paso SCAN en el segmento con el valor más alto de maxtime en SVL_QUERY_SUMMARY que tenga un valor de rows muy elevado, en comparación con el valor de rows en el paso final RETURN de la consulta. Para obtener más información, consulte Uso de la vista SVL_QUERY_SUMMARY.

Para reparar este problema, añada un predicado a la consulta o haga que el predicado existente sea más restrictivo para acotar la salida.

Conjunto de resultados muy grande

Si la consulta devuelve un conjunto de resultados muy grande, considere la posibilidad de reescribirla de forma que utilice UNLOAD para escribir los resultados en Amazon S3. Este método mejora el rendimiento del paso RETURN, ya que aprovecha el procesamiento en paralelo. Para obtener más información acerca de cómo controlar si hay conjuntos de resultados muy grandes, consulte Uso de la vista SVL_QUERY_SUMMARY.

Lista SELECT grande

Si su consulta tiene una lista SELECT excepcionalmente grande, es probable que vea un valor de bytes elevado, en comparación con el valor de rows en cualquier paso (con relación a otros pasos) en SVL_QUERY_SUMMARY. Este valor elevado de bytes puede indicar que está seleccionando muchas columnas. Para obtener más información, consulte Uso de la vista SVL_QUERY_SUMMARY.

Para reparar este problema, revise las columnas que está seleccionando y vea si se pueden eliminar.