¿Cuáles son las ventajas y desventajas de MySQL y cuándo es una buena opción?

MySQL es un sistema de gestión de bases de datos relacionales que puede utilizarse para servicios web habituales y procesamiento de transacciones en línea (OLTP), especialmente al usar el motor de almacenamiento InnoDB y sus funciones, como transacciones, bloqueo a nivel de fila y lecturas coherentes. Por otro lado, la replicación de lectura es asíncrona de forma predeterminada, y las configuraciones de alta disponibilidad, las consultas complejas y el particionamiento tienen restricciones de diseño y operación. Sus ventajas solo se convierten en ventajas reales cuando se ajustan a la carga de trabajo y a las capacidades operativas del equipo. dev.mysql.com↗ dev.mysql.com↗

Al evaluar MySQL, es más preciso considerar cómo se leen y escriben los datos, qué debe garantizarse durante los fallos y qué tan complejo llegará a ser el esquema, en lugar de preguntarse simplemente si es una «base de datos rápida». El análisis siguiente se ajusta al alcance de la documentación oficial de MySQL 8.4. El comportamiento real puede variar según la versión, el motor de almacenamiento, la configuración y la topología de replicación. dev.mysql.com↗

¿Qué tipo de base de datos es MySQL?

Una base de datos relacional almacena datos en tablas compuestas por filas y columnas, y utiliza el lenguaje de consulta SQL para gestionar las relaciones entre las tablas. Por ejemplo, una tienda en línea puede utilizar tablas como customers, orders y order_items para gestionar las relaciones entre clientes, pedidos y productos solicitados. En muchos casos es necesario agrupar varios cambios en una sola operación, como crear un pedido, reducir el inventario y registrar el estado del pago.

Los motores de almacenamiento son importantes en MySQL. Un motor de almacenamiento es un componente responsable de cómo se almacenan, bloquean y recuperan las tablas. En particular, InnoDB es el motor de almacenamiento predeterminado de MySQL y proporciona transacciones ACID, confirmaciones y reversiones, recuperación tras fallos, bloqueo a nivel de fila, control de concurrencia multiversión (MVCC) y claves foráneas. Por lo tanto, la fiabilidad transaccional asociada habitualmente con MySQL suele referirse a MySQL que utiliza tablas InnoDB configuradas correctamente. dev.mysql.com↗

ACID es un término colectivo para las propiedades esperadas de las transacciones. La atomicidad significa que una operación completa tiene éxito o se cancela. La consistencia significa que se mantienen las reglas de datos definidas. El aislamiento controla los efectos que las operaciones ejecutadas simultáneamente tienen entre sí, mientras que la durabilidad significa que los resultados confirmados deben sobrevivir a los fallos. Las características ACID de MySQL también se ven afectadas por el motor, la configuración, el hardware y los procedimientos operativos, por lo que el nombre por sí solo no debe entenderse como una solución automática para todos los escenarios de fallo. dev.mysql.com↗

¿Por qué las transacciones y la concurrencia de InnoDB son una ventaja?

OLTP se refiere a cargas de trabajo con solicitudes frecuentes y relativamente breves, como recibir pedidos, actualizar información de miembros o cambiar el estado de un pago. En este entorno, muchos usuarios pueden modificar simultáneamente los mismos tipos de datos, por lo que es importante agrupar los cambios de datos de forma segura y mantener el alcance de los conflictos lo más reducido posible.

Dado que InnoDB proporciona confirmaciones de transacciones, reversiones y recuperación tras fallos, se puede configurar una aplicación para revertir una transacción si falla un paso durante, por ejemplo, la creación de un pedido y la reducción del inventario. El bloqueo a nivel de fila bloquea filas específicas según sea necesario y puede ser más favorable para permitir trabajo simultáneo que bloquear ampliamente una tabla completa. Sin embargo, las esperas y los conflictos no desaparecen cuando varias operaciones compiten con frecuencia por las mismas filas o por rangos de datos adyacentes. dev.mysql.com↗

MVCC proporciona lecturas coherentes mediante el uso de múltiples versiones de los datos. No significa simplemente que las lecturas y las escrituras nunca interfieran entre sí. Los resultados observados y el comportamiento de bloqueo pueden diferir según el nivel de aislamiento de una transacción, las sentencias SQL que se ejecuten y si se utilizan lecturas con bloqueo. Por lo tanto, al resolver problemas de concurrencia, no compruebe solo el nombre del motor. Primero defina, en las reglas de negocio, qué lecturas deben ver el valor más reciente y qué actualizaciones deben ser mutuamente excluyentes.

Una clave foránea es una restricción que ayuda a garantizar que un valor de una tabla haga referencia a una fila existente en otra tabla. Por ejemplo, puede exigir que el ID de cliente de un pedido apunte a un cliente real. Esto puede ayudar a reducir las referencias no válidas, pero también implica que las reglas de eliminación y actualización, así como la estructura de las tablas, deben diseñarse cuidadosamente de antemano. Si planea introducir particionamiento más adelante, también debe comprobar las restricciones de compatibilidad relacionadas con las claves foráneas. dev.mysql.com↗ dev.mysql.com↗

¿Qué ventajas ofrece para los entornos de desarrollo y el control de acceso?

MySQL proporciona múltiples protocolos de cliente y API para C/C++, Java, PHP, Python, Ruby y otros lenguajes. Por ello, las aplicaciones que ya utilizan estos lenguajes y herramientas tienen opciones para construir una capa de conexión, y puede ser relativamente sencillo establecer una ruta básica entre una aplicación web y la base de datos. Sin embargo, la existencia de una API para un lenguaje concreto no garantiza por sí sola que el agrupamiento de conexiones, los reintentos ante errores, los conjuntos de caracteres y el manejo de zonas horarias estén configurados correctamente. El enfoque de acceso a datos de la aplicación debe validarse por separado. dev.mysql.com↗

El sistema de privilegios también forma parte del diseño operativo. MySQL proporciona privilegios a nivel global, de base de datos y de objeto, además de privilegios dinámicos. Esto puede usarse para separar roles: por ejemplo, otorgar a una cuenta de aplicación solo los permisos de lectura y escritura que necesita para tablas determinadas, mientras se usan cuentas independientes para tareas de copia de seguridad y administración. El principio de mínimo privilegio es un principio de diseño útil para limitar el impacto si una cuenta se ve comprometida o un programa contiene un error. dev.mysql.com↗

No obstante, hacer los privilegios más granulares no completa por sí mismo la seguridad. En la práctica, debe gestionar qué cuentas tienen qué privilegios, si las cuentas de administrador y de aplicación están separadas, y qué proceso rige los cambios de privilegios. En otras palabras, las funciones de privilegios de MySQL proporcionan mecanismos de control, pero la responsabilidad de asignarlos según los roles de negocio sigue recayendo en las operaciones.

¿Qué problemas resuelven los índices y el particionamiento?

Un índice es una estructura de datos diseñada para reducir la necesidad de recorrer una tabla completa para encontrar las filas deseadas. Por ejemplo, si son frecuentes las solicitudes para encontrar un único pedido por número de pedido, un índice sobre esa columna puede ayudar. Los índices multicolumna pueden ser útiles para consultas que usan varias columnas conjuntamente como condiciones, pero el orden de las columnas y los predicados reales de la consulta importan. InnoDB admite hasta 64 índices secundarios por tabla y hasta 16 columnas por índice multicolumna. dev.mysql.com↗

Sin embargo, los índices no mejoran automáticamente al crear más de ellos. Consumen espacio de almacenamiento y también deben mantenerse cuando se insertan, actualizan o eliminan filas. El límite en el número de índices admitidos es un límite técnico, no un objetivo de diseño. Si un índice que acorta una ruta de búsqueda es realmente necesario y qué carga añade a las rutas de escritura deben evaluarse con consultas representativas y la distribución de los datos.

Los índices de cadenas también tienen restricciones físicas. El límite del prefijo de clave de índice de InnoDB es generalmente de 3.072 bytes, aunque puede reducirse a 767 bytes según el formato de fila. Si intenta indexar cadenas largas con un conjunto de caracteres que ocupa mucho almacenamiento por carácter, como utf8mb4, este límite puede afectar al diseño del esquema. Es especialmente importante distinguir que se trata de un límite basado en bytes, no en el número de caracteres. dev.mysql.com↗

El particionamiento es una función que almacena una tabla en varias particiones conforme a reglas definidas. Si una condición coincide con las reglas de particionamiento, la poda de particiones puede excluir las particiones que MySQL no necesita buscar. Por ejemplo, para una tabla de historial grande consultada por intervalo de fechas, si la tabla está particionada por fecha, puede considerar un diseño que reduzca el rango objetivo para las búsquedas de un período específico. dev.mysql.com↗

Eso no significa que toda tabla grande deba particionarse. Si las condiciones usadas habitualmente no coinciden con la clave de partición, es posible que no se produzca la reducción esperada de los datos objetivo. El particionamiento también introduce reglas adicionales para las operaciones, el diseño de claves y las restricciones, por lo que es mejor comparar primero si el problema puede resolverse con índices más sencillos y mejoras en las consultas.

¿Qué restricciones se aplican al particionamiento y a la búsqueda de texto completo?

En MySQL 8.4, el particionamiento es compatible con los motores de almacenamiento InnoDB y NDB. Una tabla InnoDB particionada no puede tener claves foráneas ni ser el destino de referencias de clave foránea desde otra tabla. Además, cada columna usada en la clave de partición debe formar parte de cada clave única, incluida la clave primaria. Esta condición puede cambiar significativamente el modelo cuando intenta particionar una tabla principal con referencias densas, como una tabla de pedidos. dev.mysql.com↗

La búsqueda de texto completo es una función para buscar texto por palabras. MySQL admite búsqueda de texto completo con InnoDB y MyISAM, pero no se admite en tablas particionadas. Por lo tanto, si espera disponer en la misma tabla tanto de funcionalidad de búsqueda para documentos largos como de particionamiento para datos históricos a gran escala, debe verificar desde el principio si esa combinación es posible. Añadir una función más adelante puede requerir dividir tablas o cambiar la arquitectura de búsqueda. dev.mysql.com↗

Estas restricciones no muestran simplemente que MySQL carezca de funciones, sino que las funciones pueden no combinarse de forma independiente. Puede comprobar una por una la necesidad de claves foráneas, claves únicas, claves de partición y búsqueda de texto completo. Es más seguro evitar decidir un esquema basándose en el beneficio de una sola función.

¿Cómo puede usarse la replicación para escalar las lecturas y realizar copias de seguridad?

La replicación es una arquitectura que envía cambios de un servidor a otro. Normalmente, un servidor fuente registra los cambios y los servidores réplica los aplican. Distribuir algunas solicitudes de lectura entre varias réplicas puede reducir la carga de lectura de la fuente, y también puede considerar descargar tareas de copia de seguridad o análisis a las réplicas. dev.mysql.com↗

GTID es un método para gestionar las posiciones de replicación mediante la asignación de un identificador a cada transacción. La replicación basada en GTID puede ayudar a reducir la carga de alinear manualmente nombres y posiciones de archivos de registro binario. Sin embargo, establecer una topología de replicación es distinto de supervisar el retraso de replicación y operar los procedimientos de recuperación. Debe determinar qué servidor gestiona las escrituras, qué servidores pueden atender lecturas y qué hacer cuando se produce retraso. dev.mysql.com↗

La replicación predeterminada es asíncrona. Esto significa que, en el instante en que se completa una confirmación en la fuente, no hay garantía de que todas las réplicas hayan aplicado el mismo cambio. Por ejemplo, una consulta dirigida a una réplica inmediatamente después de que un usuario cambie su dirección puede mostrar la dirección anterior. Esto puede considerarse un problema de consistencia de lectura tras escritura. Las solicitudes que deben tener los datos más recientes necesitan una política que las dirija a la fuente o que tenga en cuenta el estado de aplicación de la réplica. dev.mysql.com↗

La replicación semisincrónica utiliza un enfoque en el que la fuente recibe confirmación de que una réplica ha recibido y registrado un evento de transacción. Es una alternativa a la replicación asíncrona predeterminada, pero no significa que todos los requisitos se vuelvan completamente sincrónicos. Al analizar requisitos sincrónicos estrictos, defina claramente el nivel de consistencia requerido, el intervalo de latencia aceptable y el comportamiento ante fallos, y considere también opciones independientes como NDB Cluster. dev.mysql.com↗

¿Group Replication resuelve automáticamente la alta disponibilidad?

La alta disponibilidad es el objetivo de configurar un sistema de modo que un servicio pueda continuar cuando falla parte de un servidor o de la red. Group Replication gestiona la pertenencia al grupo, elige automáticamente una primaria en modo de primaria única o admite configuraciones de múltiples primarias. Su capacidad de formar una topología de alta disponibilidad al combinarse con InnoDB Cluster y MySQL Router es una opción importante de MySQL. dev.mysql.com↗

Sin embargo, el consenso entre servidores de bases de datos y la conmutación por error de las conexiones de la aplicación no son el mismo problema. Group Replication no incluye funcionalidad para cambiar clientes fallidos a miembros en buen estado. Las aplicaciones necesitan MySQL Router, un balanceador de carga, un conector o middleware personalizado para determinar dónde conectarse, y esa capa también debe operarse teniendo en cuenta fallos, reintentos y actualizaciones de estado. dev.mysql.com↗

Por lo tanto, cuando oiga «conmutación por error automática», formule al menos tres preguntas distintas. Primero, ¿puede elegirse una primaria? Segundo, ¿las nuevas conexiones de la aplicación se dirigen a un servidor en buen estado? Tercero, ¿qué resultados verán las solicitudes en curso y las solicitudes reintentadas por el usuario? La existencia de una función para la primera pregunta no garantiza automáticamente las otras dos.

Una configuración de múltiples primarias tampoco debe entenderse simplemente como un interruptor para aumentar el rendimiento de escritura. Cuando se permiten escrituras desde varios lugares, también debe diseñar cómo se evitarán o gestionarán a nivel de negocio las modificaciones simultáneas de los mismos datos, y qué reglas debe seguir la ruta de escritura de la aplicación. La alta disponibilidad es una cuestión operativa que incluye no solo la selección de funciones, sino también simulacros de fallos, observabilidad y procedimientos de recuperación.

¿Por qué las consultas complejas pueden aumentar la carga de ajuste?

El optimizador es un componente que elige el plan de ejecución con el menor coste estimado entre varias formas de ejecutar una sentencia SQL. Por ejemplo, determina qué índice usar primero y el orden en que se unirán las tablas. El optimizador basado en costes de MySQL puede depender de estimaciones cuando las estadísticas son insuficientes, por lo que puede elegir un plan distinto del que esperaría una persona. dev.mysql.com↗

A medida que aumenta el número de tablas unidas, el número de planes de ejecución candidatos puede crecer exponencialmente. En ese caso, no solo la recuperación de datos en sí, sino también el tiempo de optimización necesario para explorar planes adecuados puede convertirse en un cuello de botella. Por ello, en sistemas que ejecutan con frecuencia consultas analíticas complejas o muchas uniones, resulta difícil determinar la idoneidad basándose solo en si el SQL puede ejecutarse sintácticamente. Las pruebas deben usar distribuciones de datos reales y condiciones representativas. dev.mysql.com↗

EXPLAIN es una herramienta para comprobar el plan de ejecución seleccionado para una consulta. Cuando los resultados son lentos, primero inspeccione los predicados, las condiciones de unión, los índices utilizados y los recuentos de filas estimados. Si es necesario, puede actualizar las estadísticas o ajustar los índices y la estructura de la consulta. También están disponibles las sugerencias de índices y las funciones de control del optimizador, pero los enfoques que fuerzan un plan determinado deben verificarse continuamente para asegurar que sigan siendo válidos después de cambios en los datos. dev.mysql.com↗ dev.mysql.com↗

Esto no significa que no puedan realizarse análisis complejos en MySQL. Sin embargo, si las uniones de muchas tablas a gran escala y las consultas analíticas son la carga de trabajo principal, es realista comparar de antemano cuánto tiempo puede dedicar al ajuste, si los análisis deberían descargarse a réplicas y si se debe añadir un sistema analítico dedicado. Por el contrario, esta carga puede ser relativamente menor para un servicio compuesto principalmente por transacciones cortas y predecibles.

¿Cuándo debe tener cuidado con las rutinas almacenadas?

Las rutinas almacenadas son procedimientos o funciones almacenados y ejecutados en el servidor de base de datos. Pueden mantener algunas reglas de procesamiento de datos cerca de la base de datos, pero las funciones almacenadas que pueden utilizarse en sentencias SQL tienen restricciones. Por ejemplo, una función almacenada no puede usar una sentencia que devuelva un conjunto de resultados. Una función que calcula un único valor de retorno y una operación de consulta que devuelve varias filas tienen finalidades y patrones de uso diferentes. dev.mysql.com↗ dev.mysql.com↗

El determinismo de las rutinas almacenadas también importa en entornos de replicación. Determinista significa producir el mismo resultado para la misma entrada. Las rutinas no deterministas o dependientes del tiempo, que varían según el tiempo o el estado del entorno, pueden crear problemas de reproducibilidad según el método de replicación, lo que requiere especial cuidado con la replicación basada en sentencias. Al colocar lógica de negocio en la base de datos, también debe revisar si esa lógica puede producir el mismo resultado durante la replicación y la recuperación tras fallos. dev.mysql.com↗

La decisión de usar rutinas almacenadas tiene menos que ver con si existe una función que con dónde deben residir la responsabilidad de los cambios, las pruebas y la implementación. Cuando las reglas se dividen entre el código de la aplicación y las rutinas de la base de datos, el seguimiento y las pruebas pueden volverse más complejos. Por el contrario, pueden ser útiles para reglas sencillas cercanas a la integridad de los datos. La cuestión clave es si el equipo puede entender y gestionar dónde se ejecutan esas reglas y su impacto en la replicación.

¿Cuándo es MySQL una buena opción y cuándo debe actuar con cautela?

La siguiente tabla no es una clasificación de productos. Es una perspectiva para comprobar la adecuación entre los requisitos y las funciones.

Las tres primeras filas de la tabla se basan en las funciones oficiales de InnoDB, la replicación y Group Replication. Las dos últimas también reflejan el comportamiento y las restricciones del particionamiento y el optimizador. dev.mysql.com↗ dev.mysql.com↗ dev.mysql.com↗ dev.mysql.com↗ dev.mysql.com↗

En particular, si la consistencia sólida entre varias regiones o la conmutación por error ininterrumpida son requisitos fundamentales, no debe tomar una decisión basándose únicamente en la replicación asíncrona predeterminada. Especifique los requisitos de actualización de datos, la latencia aceptable, si las escrituras siguen siendo posibles durante los fallos y la ruta de conmutación por error de la aplicación; después, compare Group Replication, NDB Cluster u otras opciones distribuidas. Por el contrario, si desea procesar de forma fiable transacciones típicas de lectura y escritura dentro de una única área de servicio y distribuir las lecturas a réplicas según sea necesario, la combinación de funciones de MySQL puede ser un punto de partida práctico. dev.mysql.com↗ dev.mysql.com↗

¿Qué debe comprobar antes de adoptarlo?

Primero, verifique que las tablas principales utilizan InnoDB y que los límites de las transacciones coinciden con las unidades de negocio. Los cambios que deben tener éxito o fallar juntos, como crear un pedido, deben definirse como una única transacción, evitando al mismo tiempo transacciones innecesariamente largas que aumenten la duración de los bloqueos. Segundo, enumere las consultas de lectura y escritura más frecuentes y compruebe que los índices requeridos coincidan con los predicados y el método de ordenación reales. dev.mysql.com↗ dev.mysql.com↗

Tercero, si usa replicación, decida «qué lecturas se permiten desde las réplicas». Un enfoque consiste en distinguir las solicitudes que requieren datos actualizados, como comprobar un estado inmediatamente después de un pago, de las consultas de listas y estadísticas que pueden tolerar cierto retraso. Cuarto, si se requiere una configuración de alta disponibilidad, pruebe escenarios de fallo no solo para la elección de miembros de la base de datos, sino también para el lugar al que realmente se trasladan las conexiones de la aplicación. dev.mysql.com↗ dev.mysql.com↗

Quinto, suponga que los datos crecerán y compruebe si el particionamiento es realmente necesario y si puede aceptar las restricciones de claves foráneas y claves únicas. Si necesita conjuntamente búsqueda de cadenas largas, búsqueda de texto completo y particionamiento, revise primero las limitaciones entre las funciones. Por último, si las uniones complejas son centrales, inspeccione EXPLAIN en condiciones cercanas a los datos de producción y evalúe si tiene capacidad para gestionar continuamente las estadísticas y los cambios de índices. dev.mysql.com↗ dev.mysql.com↗ dev.mysql.com↗

Conclusión: ¿cómo debe evaluar las ventajas y desventajas de MySQL?

Entre las fortalezas de MySQL se encuentran el control de transacciones y concurrencia basado en InnoDB, la integración con una amplia variedad de entornos de desarrollo, la distribución de lecturas mediante replicación y las funciones oficiales para crear configuraciones de alta disponibilidad. Estas pueden proporcionar una base significativa para servicios web generales y cargas de trabajo OLTP típicas. dev.mysql.com↗ dev.mysql.com↗ dev.mysql.com↗

Al mismo tiempo, el posible retraso de la replicación predeterminada, el diseño adicional necesario para la conmutación por error de conexiones de alta disponibilidad, la validación de planes de ejecución para consultas complejas y las restricciones relacionadas con índices, particionamiento y búsqueda de texto completo deben considerarse costes reales. En última instancia, MySQL no es una elección con cualidades positivas universales. Es una base de datos cuya idoneidad puede evaluarse cuando se concretan los requisitos de consistencia de datos, la proporción de lectura y escritura, las restricciones del esquema, el nivel de respuesta ante fallos y la capacidad de ajuste y operación. dev.mysql.com↗ dev.mysql.com↗ dev.mysql.com↗