Mejora del rendimiento de las consultas

A continuación, se describen algunos problemas frecuentes que afectan al rendimiento de las consultas de Amazon Redshift 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:

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:

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:

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:

Distribución de datos poco óptima

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

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 Distribución de datos para la optimización de consultas.

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.