Ajustar el rendimiento y mantener las bases de datos en Azure Database for MySQL - Servidor flexible utilizando el sys_schema

SE APLICA A: Azure Database for MySQL (servidor único) Azure Database for MySQL (servidor flexible)

Importante

El servidor único de Azure Database for MySQL está en proceso de retirada. Es muy recomendable actualizar al servidor flexible de Azure Database for MySQL. Para obtener más información sobre la migración al servidor flexible de Azure Database for MySQL, consulte ¿Qué sucede con el servidor único de Azure Database for MySQL?

La característica performance_schema de MySQL, disponible por primera vez en MySQL 5.5, proporciona instrumentación para muchos recursos importantes del servidor como la asignación de memoria, programas almacenados, bloqueo de metadatos, etc. No obstante, performance_schema contiene más de 80 tablas y obtener la información necesaria a menudo requiere unir las tablas de performance_schema y las tablas procedentes de information_schema. Basado en performance_schema e information_schema, el sys_schema proporciona una potente colección de vistas fáciles de usar en una base de datos de solo lectura y está totalmente habilitado en el servidor flexible de Azure Database for MySQL versión 5.7.

Hay 52 vistas en sys_schema y cada vista tiene uno de los siguientes prefijos:

• Host_summary o IO: latencias relacionadas con E/S.
• InnoDB: estado y bloqueos del búfer InnoDB.
• Memoria: uso de la memoria por parte del host y de los usuarios.
• Esquema: información relacionada con los esquemas, como el incremento automático, los índices, etc.
• Statement: información sobre las instrucciones SQL. Puede tratarse de una instrucción que dio como resultado un recorrido de tabla completo o un tiempo de consulta largo.
• User: los recursos que consumen y agrupan los usuarios. Algunos ejemplos son: operaciones de E/S de archivo, conexiones y memoria.
• Wait: eventos de espera agrupados por host o usuario.

Echemos un vistazo a algunos patrones de uso habituales de sys_schema. Para empezar, vamos a agrupar los patrones de uso en dos categorías: Ajuste de rendimiento y Mantenimiento de la base de datos.

Optimización del rendimiento

sys.user_summary_by_file_io

E/S es la operación más costosa en la base de datos. Podemos averiguar el promedio de latencia de E/S consultando la vista sys.user_summary_by_file_io. Con el valor predeterminado de 125 GB de almacenamiento aprovisionado, la latencia de E/S es aproximadamente de 15 segundos.

Debido a que el servidor flexible de Azure Database for MySQL escala E/S con respecto al almacenamiento, después de aumentar mi almacenamiento aprovisionado a 1 TB, mi latencia E/S se reduce a 571 ms.

sys.schema_tables_with_full_table_scans

A pesar de efectuar un planeamiento cuidadoso, puede que muchas consultas aún resulten en recorridos de tabla completos. Para obtener más información sobre los tipos de índices y cómo optimizarlos, puede consultar este artículo: Cómo solucionar problemas de rendimiento de las consultas. Los recorridos de tabla completos requieren un uso intensivo de los recursos y reducen el rendimiento de la base de datos. La forma más rápida de buscar tablas con recorridos de tabla completos es consultar la vista sys.schema_tables_with_full_table_scans.

sys.user_summary_by_statement_type

Para solucionar los problemas de rendimiento de bases de datos, puede resultar útil identificar los eventos que se producen dentro de la base de datos y mediante la vista sys.user_summary_by_statement_type puede lograrlo.

En este ejemplo, el servidor flexible de Azure Database for MySQL empleó 53 minutos en vaciar el registro de consultas lentas 44 579 veces. Eso es mucho tiempo y muchas E/S. Puede reducir esta actividad deshabilitando el registro de consultas lentas o reduciendo la frecuencia de este registro en Azure Portal.

Mantenimiento de base de datos

sys.innodb_buffer_stats_by_table

[!IMPORTANTE]

La consulta de esta vista puede afectar al rendimiento. Se recomienda llevar a cabo esta solución de problemas durante el horario comercial fuera de horas punta.

El grupo de búferes InnoDB reside en la memoria y es el principal mecanismo de memoria caché entre el sistema de administración de bases de datos y el almacenamiento. El tamaño del grupo de búferes InnoDB está vinculado al nivel de rendimiento y no se puede cambiar a menos que se elija una SKU de producto diferente. Al igual que con la memoria del sistema operativo, se intercambiaron páginas antiguas para dejar espacio a los datos más recientes. Para averiguar qué tablas consumen la mayor parte de la memoria del grupo de búferes InnoDB, puede consultar la vista sys.innodb_buffer_stats_by_table.

En el gráfico anterior, se puede ver que aparte de las tablas del sistema y las vistas, cada tabla de la base de datos mysqldatabase033, que hospeda uno de mis sitios de WordPress, ocupa 16 KB, o 1 página, de datos en memoria.

Sys.schema_unused_indexes & sys.schema_redundant_indexes

Los índices son unas herramientas estupendas para mejorar el rendimiento de lectura, pero suponen costos adicionales por las inserciones y el almacenamiento. Sys.schema_unused_indexes and sys.schema_redundant_indexes proporcionan información sobre los índices sin usar o los duplicados.

Conclusión

En resumen, sys_schema es una herramienta excelente para la optimización de rendimiento y el mantenimiento de base de datos. Asegúrese de aprovechar esta función en su instancia de servidor flexible de Azure Database for MySQL.

Pasos siguientes

• Para buscar respuestas de otros usuarios a sus preguntas o publicar una nueva pregunta o respuesta, visite Stack Overflow.