Use the SQL optimization feature - Database Autonomy Service - Centro de documentación de Alibaba Cloud

Database Autonomy Service (DAS) ofrece una función de optimización SQL que genera automáticamente resultados de diagnóstico, sugerencias de optimización y estimaciones de mejora de rendimiento. Puede revisar estos resultados para decidir si adopta las sugerencias. Este tema describe cómo utilizar la función de optimización SQL.

Requisitos previos

El motor de base de datos es uno de los siguientes:
- RDS for MySQL
  
  Nota
  Las ediciones Basic y Cluster de RDS for MySQL no son compatibles.
- MyBase MySQL
- PolarDB for MySQL
  
  Nota
  Los clústeres de nodo único (anteriormente instancias independientes) de PolarDB for MySQL no son compatibles.
- PolarDB-X 2.0
  
  Nota
  Las instancias de PolarDB-X 2.0 con versión principal 5.4.13 y una versión secundaria en el rango [16415631,16504348] no son compatibles. Para consultar la versión de su instancia de PolarDB-X 2.0, consulte View and upgrade an instance version.
- MongoDB
La instancia objetivo está conectada a DAS. Para obtener más información, consulte Connect an instance to DAS.
El estado de acceso de la instancia objetivo es Normal Access.

Limitaciones

No es posible diagnosticar ni optimizar sentencias SQL para tablas que utilizan X-Engine.
En PolarDB-X, si ejecuta una sentencia SQL mediante una sentencia preparada, el registro de consultas lentas almacena por separado la plantilla de la sentencia (por ejemplo, select * from test where a = ? and b = ?) y los parámetros vinculados (por ejemplo, params: [1, 2]). Dado que este formato no se puede ejecutar directamente como una sentencia SQL válida, las funciones que dependen de la sentencia original para su análisis u optimización podrían verse limitadas.

Crear un análisis SQL visual a partir de registros lentos

Esta función presenta flujos complejos de ejecución SQL en un formato visual e intuitivo. Su interfaz gráfica muestra claramente la ruta de ejecución de la consulta, la eficiencia de los nodos y los posibles cuellos de botella, lo que le permite identificar y resolver problemas rápidamente durante la optimización SQL, las revisiones de código y las comprobaciones de estado.

Importante

La optimización SQL en la página Slow Log Analysis solo es compatible con instancias de RDS for MySQL 5.6, 5.7, and 8.0 y PolarDB for MySQL 5.6, 5.7, and 8.0.

Inicie sesión en la consola de DAS.
En el panel de navegación izquierdo, haga clic en Intelligent O&M Center > Instance Monitoring.
Localice la instancia objetivo y haga clic en el ID de la instancia para abrir la página de detalles de la instancia.
En el panel de navegación izquierdo, haga clic en Request Analysis > Slow Logs.
En la página Slow Log Analysis:
- En la pestaña Slow Log Statistics, localice la plantilla SQL objetivo y haga clic en Optimize en la columna Actions.
- En la pestaña Slow Log Details, localice la sentencia SQL objetivo y haga clic en Optimize en la columna Actions.
En el cuadro de diálogo que aparece, haga clic en Create Plan.
Seleccione un tipo de nodo de ejecución.
- Standby node (predeterminado): El nodo en espera de la instancia actual. Este nodo se utiliza principalmente para el análisis de consultas rutinarias.
- Event node: El nodo de negocio donde se ejecutó realmente la sentencia SQL. Este nodo es adecuado para la resolución de problemas y la optimización.
Haga clic en Confirm Creation para crear un Visual Execution Plan.

Plan de ejecución visual

Importante

El plan de ejecución visual refleja el estado de ejecución actual, no un registro histórico.
La matriz visual se adapta a la complejidad de la sentencia SQL. Si el gráfico contiene mucho contenido, utilice la herramienta de zoom para ajustar la escala de visualización o haga clic en el botón de restablecimiento para volver a la vista inicial.

En un plan de ejecución visual, el flujo de ejecución va de abajo hacia arriba y de izquierda a derecha. El nodo inferior es el punto de inicio de la consulta. Los datos fluyen hacia arriba capa por capa hasta que se devuelve el resultado final. Ejemplo:

Colores de los nodos

Nodo eficiente (verde): Indica un método de acceso eficiente, que incluye: system, const, eq_ref, ref, ref_or_null y index_merge.
Nodo moderadamente eficiente (amarillo): Indica un método de acceso subóptimo, que incluye: fulltext, unique_subquery, index_subquery y range.
Nodo ineficiente (rojo): Indica un método de acceso ineficiente al que se debe dar prioridad para su optimización, que incluye: all y index.

Detalles del nodo

Parte superior: Muestra el tipo de nodo, como TABLE_SCAN o INDEX_SCAN.
Izquierda: El costo, una métrica relativa estimada por el optimizador basada en factores como CPU, memoria y E/S de disco.
Derecha: El número estimado de filas devueltas, que indica el volumen de procesamiento de datos.

Sugerencia de optimización

Dé prioridad a la optimización de los nodos ineficientes marcados en rojo para mejorar significativamente el rendimiento de las consultas.

Glosario

Término	Nombre común	Descripción
QUERY_BLOCK	bloque de consulta	Unidad semántica de una sentencia SQL. Cada consulta o subconsulta independiente constituye un bloque de consulta, identificado por `select_id` en la salida de EXPLAIN.
ATTACHED_SUBQUERIES	subconsulta adjunta	Subconsulta vinculada a una cláusula `WHERE`, `HAVING` u `ON` mediante predicados como `EXISTS`, `IN` o `ANY`. Este tipo de subconsulta tiene una dependencia lógica respecto a la consulta principal.
CORRELATED_SUBQUERY	subconsulta correlacionada	Consulta anidada que hace referencia a columnas de una consulta externa. Requiere vinculación con valores de contexto externos durante la ejecución y puede generar una complejidad O(n²).
NON_CORRELATED_SUBQUERY	subconsulta no correlacionada	Subconsulta autónoma que se puede ejecutar independientemente de la consulta externa. Por lo general, el optimizador la precalcula y materializa como una constante.
MATERIALIZED_FROM_SUBQUERY	subconsulta materializada	Estrategia de optimización introducida en MySQL 5.6+. Conserva el resultado de la subconsulta en una tabla temporal en memoria y suele asociarse con una tabla derivada en formato `subqueryN`.
OPTIMIZED_AWAY_SUBQUERIES	subconsulta eliminada por optimización	Subconsulta que se elimina por completo tras la optimización de reescritura de consultas, como la inserción de subconsultas constantes. No aparece en el plan de ejecución final.
QUERY_SPECIFICATIONS	estructura de especificación de consulta	Unidad semántica completa que describe los elementos sintácticos de una consulta, incluida la lista SELECT, la cláusula FROM y las condiciones de filtro.
SELECT_LIST_SUBQUERIES	subconsulta de lista de selección	Subconsulta escalar que aparece en las columnas de proyección (lista de campos SELECT). Debe devolver un único valor escalar por cada iteración.
INDEX_SCAN	exploración de índice	Patrón de acceso a datos que utiliza un índice de árbol B+. Las exploraciones pueden ser directas o inversas, y pueden implicar búsquedas en tablas.
TABLE_SCAN	exploración completa de tabla	Método de acceso en el que el optimizador explora todas las páginas del índice agrupado. Esto ocurre cuando no hay ningún índice adecuado disponible o cuando la proporción de datos a los que se debe acceder supera un umbral. El rendimiento disminuye a medida que aumenta el volumen de datos.
ORDERING_OPERATION	ordenamiento del conjunto de resultados	Operación ORDER BY que clasifica el conjunto de resultados mediante un algoritmo de ordenamiento explícito, como filesort. Esta operación puede utilizar memoria o archivos temporales en disco.
NESTED_LOOP	unión de bucle anidado	Implementación más básica de un algoritmo de unión de tablas. Para cada fila de la tabla externa, itera a través de las filas coincidentes en la tabla interna. Es eficiente cuando el predicado de unión proporciona un filtrado eficaz.
DUPLICATES_REMOVAL	deduplicación de resultados	Operación que implementa la semántica DISTINCT. La implementación subyacente puede usar un índice único en una tabla temporal, u ordenar y luego filtrar los resultados. El costo depende de las características de distribución de los datos.
WINDOWING_OPERATION	cálculo de función de ventana	Cálculo de función analítica (como `ROW_NUMBER` o `RANK`) realizado sobre una ventana de datos definida por una cláusula OVER(). Puede requerir la ordenación del conjunto de datos completo.
TABLE	referencia de tabla base	Objeto de almacenamiento físico al que se accede directamente en el plan de ejecución. Contiene información como el nombre de la tabla, el alias y el método de acceso (por ejemplo, `const`, `system` o `range`).

Optimizar SQL desde la página Instance Sessions

Importante

Las instancias autogestionadas de MySQL, MongoDB y RDS for PostgreSQL no admiten la optimización SQL en la página Instance Sessions.

Inicie sesión en la consola de DAS.
En el panel de navegación izquierdo, haga clic en Intelligent O&M Center > Instance Monitoring.
Localice la instancia objetivo y haga clic en el ID de la instancia para abrir la página de detalles de la instancia.
En el panel de navegación izquierdo, haga clic en Instance Sessions.
En el área Instance Sessions, seleccione la sesión que desea optimizar y haga clic en Optimize.
En el cuadro de diálogo SQL Diagnostic Optimization que aparece, consulte los resultados del diagnóstico SQL.

Si acepta la sugerencia, haga clic en Copy en la esquina superior derecha y pegue el SQL optimizado en su cliente de base de datos o en DMS para su ejecución. Si no acepta la sugerencia, haga clic en Cancel para cerrar el cuadro de diálogo.

Nota
DAS diagnostica las sentencias SQL según su complejidad, el volumen de datos de la tabla y la carga de la base de datos. Un diagnóstico puede tardar más de 20 segundos. Posteriormente, el motor proporciona resultados de diagnóstico, sugerencias de optimización y estimaciones de mejora de rendimiento para que los revise y adopte.

Una vez completado el diagnóstico, la página muestra el SQL original, el plan de ejecución (incluidas columnas como select_type, type y rows), los resultados del diagnóstico (incluidas sentencias DDL para sugerencias de índices de almacenamiento en filas y detalles de índices), los beneficios de optimización (por ejemplo, "Expected performance improvement: 0.55x" y "Low optimization gains") y las sugerencias de optimización de sentencias.

Consultar el historial de diagnósticos SQL

Inicie sesión en la consola de DAS.
En el panel de navegación izquierdo, haga clic en Intelligent O&M Center > Instance Monitoring.
Localice la instancia objetivo y haga clic en el ID de la instancia para abrir la página de detalles de la instancia.
En el panel de navegación izquierdo, haga clic en Request Diagnostic History. Aquí puede consultar el historial de diagnósticos SQL de la instancia, que incluye detalles como el contenido SQL, el estado del diagnóstico, la hora y los resultados.