MySQL: una serie de malas decisiones de diseño

MySQL obviamente hizo muchas cosas buenas, de lo contrario no sería la base de datos de código abierto más popular del mundo (según Motores DB). A veces, sin embargo, me encuentro con algunas decisiones o comportamientos que son simplemente malos diseños. Muchos de estos diseños tienen mucho de razonamiento histórico detrás de ellos y tal vez todavía están allí porque no hay suficientes recursos dedicados a la vigilancia técnica de la deuda.

Me apasiona la observabilidad, especialmente cuando se trata de comprender el rendimiento del sistema. Uno de los datos más importantes para comprender el rendimiento de MySQL es comprender sus bloqueos de contenido (mutex, rwlocks, etc.).

La «mejor» manera de entender los latches en MySQL es Performance Schema. Desafortunadamente, la creación de perfiles de bloqueo está deshabilitada de forma predeterminada en el esquema de rendimiento porque provoca una sobrecarga bastante significativa; lo suficientemente significativo como para que probablemente no funcione con esta instrumentación en producción en ningún momento.

Si está buscando obtener información de exclusión mutua siempre disponible de MySQL, puede obtenerla del motor de almacenamiento InnoDB (que a menudo es bastante bueno, ya que ahí es donde está la mayor parte de la disputa).

Una opción es mirar MOSTRAR EL ESTADO DEL MOTOR INNODB salida – especialmente en la sección SEMAPHORI:

Esta sección proporciona información sobre el mutex que se espera con información sobre el tiempo de espera que puede ser muy útil. Desafortunadamente, esta información se proporciona en un formato que no se puede analizar fácilmente y solo se puede recuperar. MOSTRAR EL ESTADO DEL MOTOR INNODB salida, lo que provoca un cargo adicional y lo hace inadecuado para el muestreo de alta frecuencia.

Debido a que nunca se ha accedido a esta información con ninguna tabla INFORMATION_SCHEMA es un gran rompecabezas. ¿Fue porque la idea era que PERFORMANCE_SCHEMA debería ser la única herramienta para la observabilidad, incluso cuando el equipo de ingeniería de MySQL no puede hacerlo con una sobrecarga aceptable?

Pero espera, di … hay una mejor manera: puedes usarla MUESTRA DE MOTORES MUTEX INNODB para obtener un resumen de las estadísticas:

Este comando no proporciona la misma información (muestra el número de esperas, no la espera actual) pero es útil. El problema con este comando es que parece haber sido diseñado para ser lo menos útil posible; vea que hay muchos duplicados en «Nombre». Esto se debe a que hay muchas instancias del mismo tipo de exclusión mutua. En muchos casos, cuando desea comprender con qué tipo de contenido está tratando, desea SUMAR el número de Esperas agrupadas por Nombre y, lamentablemente, no puede hacerlo con los comandos MOSTRAR.

Aún más extraña es la elección de la sintaxis de esperas = N y nombrar una columna «Estado» donde el diseño de la base de datos relacional sugiere usar «Esperas» como nombre de columna en su lugar.

También preferirá ver el nombre del objeto de sincronización aquí, no la línea de código fuente, ya que suele ser mucho más descriptivo. MariaDB lo hace, por cierto, y también lo hace disponible como información del esquema de la tabla innodb_mutex.

Por último, tenga en cuenta lo lento (léase: caro) que es este comando: 0,6 segundos en un grupo de búfer de 80 GB. La razón es que captura el contenido mutex en las páginas del grupo de búfer, lo que es muy útil para identificar disputas específicas de la página, pero también requiere agregar información para millones de objetos que pueden consumir mucho tiempo.

Creo que la tabla INFORMATION_SCHEMA sería una opción mucho mejor para ver esta información también.

De acuerdo, entonces no podemos ejecutar SELECCIONAR claro y simple en la tabla INFORMACION_ESQUEMA para obtener los datos en una forma fácilmente digerible, pero ¿tal vez deberíamos escribir un procedimiento almacenado en su lugar?

Esto nos lleva a otro problema de diseño. Si bien puede iterar la salida SELECT en un procedimiento fácilmente almacenado, no funciona para los comandos SHOW. Probablemente hubo una buena razón práctica para esta limitación, pero no es amigable en absoluto.

Cuando nada más ayuda, siempre hay secuencias de comandos de Shell, y también podemos usarlas para resolver este problema:

Sin embargo, si su base de datos requiere que haga esto para una recopilación de datos de la información que proporciona, ¡hay algo mal aquí!

¿Qué me gustaría ver? Creo que todas las declaraciones SHOW deben revisarse y, si no están destinadas a la depreciación, la información similar a la que proporcionan debe estar disponible en las tablas o vistas. De hecho, este trabajo ya se hizo para los comandos más comunes, pero parece que nunca se terminó.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario