# Solución de problemas de rendimiento de las bases de datos Amazon Aurora MySQL
Este tema se centra en algunos problemas comunes de rendimiento de la base de datos Aurora MySQL y en cómo solucionar o recopilar información para solucionarlos rápidamente. Dividimos el rendimiento de las bases de datos en dos categorías:
+ Rendimiento del servidor: todo el servidor de base de datos funciona más lento.
+ Rendimiento de las consultas: una o más consultas tardan más en ejecutarse.
## Opciones de monitoreo de AWS
Le recomendamos que utilice las siguientes opciones de monitoreo de AWS para solucionar el problema:
+ Amazon CloudWatch: Amazon CloudWatch monitorea los recursos de AWS y las aplicaciones que ejecuta en AWS en tiempo real. Puede utilizar CloudWatch para recopilar y hacer un seguimiento de métricas, que son las variables que puede medir en los recursos y aplicaciones. Para obtener más información, consulte [¿Qué es Amazon CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html).
Puede ver todas las métricas del sistema y la información de los procesos de sus instancias de base de datos en la Consola de administración de AWS. Puede configurar su clúster de base de datos Aurora MySQL para publicar datos de registros generales, lentos, de auditoría y de errores en un grupo de registros en Amazon CloudWatch Logs. Aquí puede ver las tendencias, mantener registros en caso de que un host se vea afectado y crear una base de referencia del rendimiento “normal” con el fin de identificar fácilmente las anomalías o los cambios. Para obtener más información, consulte [Publicación de registros de Amazon Aurora MySQL en Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md).
+ Monitoreo mejorado: para habilitar métricas adicionales de Amazon CloudWatch para una base de datos Aurora MySQL, active el monitoreo mejorado. Al crear o modificar un clúster de base de datos de Aurora, seleccione **Habilitar la monitorización mejorada**. Esto permite a Aurora publicar métricas de rendimiento en CloudWatch. Algunas de las métricas clave disponibles incluyen el uso de la CPU, las conexiones a las bases de datos, el uso del almacenamiento y la latencia de las consultas. Estas métricas pueden ayudarle a identificar los cuellos de botella de rendimiento.
La cantidad de información transferida para una instancia de base de datos es directamente proporcional a la granularidad definida en el monitoreo mejorado. Un intervalo de monitorización más corto deriva en informes más frecuentes de métricas del SO y aumenta el costo de la monitorización. Para administrar los costos, establezca diferentes granularidades para diferentes instancias en sus Cuentas de AWS. La granularidad predeterminada al crear una instancia es de 60 segundos. Para obtener más información, consulte [Costo de la monitorización mejorada](USER_Monitoring.OS.md#USER_Monitoring.OS.cost).
+ Información de rendimiento: puede ver todas las métricas de las llamadas de la base de datos. Esto incluye los bloqueos de la base de datos, las esperas y el número de filas procesadas, todo lo cual puede utilizar para solucionar problemas. Al crear o modificar un clúster de base de datos de Aurora, seleccione **Activar Información de rendimiento**. De forma predeterminada, Información de rendimiento tiene un período de retención de datos de 7 días, pero se puede personalizar para analizar las tendencias de rendimiento a largo plazo. Si desea una retención superior a 7 días, debe actualizar el nivel de pago. Para obtener más información, consulte [Precio de Información de rendimiento](https://aws.amazon.com/rds/performance-insights/pricing/). Puede configurar el período de retención de datos para cada instancia de base de datos de Aurora por separado. Para obtener más información, consulte [Monitoreo de la carga de base de datos con Performance Insights en Amazon Aurora](USER_PerfInsights.md).
## Motivos más comunes de los problemas de rendimiento de bases de datos Aurora MySQL
Puede utilizar los siguientes pasos para solucionar problemas de rendimiento en la base de datos Aurora MySQL. Indicamos los pasos en el orden lógico de investigación, pero no tienen por qué ser lineales. Al realizar un descubrimiento, podría ser necesario saltar a diferentes pasos, por lo que se permiten muchas rutas de investigación.
1. [Carga de trabajo](aurora-mysql-troubleshooting-workload.md): comprenda la carga de trabajo de su base de datos.
1. [Registro](aurora-mysql-troubleshooting-logging.md): revise todos los registros de la base de datos.
1. [Conexiones a bases de datos](mysql-troubleshooting-dbconn.md): asegúrese de que las conexiones entre las aplicaciones y la base de datos sean fiables.
1. [Rendimiento de consultas](aurora-mysql-troubleshooting-query.md): examine sus planes de ejecución de consultas para ver si han cambiado. Los cambios en el código pueden provocar cambios en los planes.
# Solución de problemas de carga de trabajo de bases de datos Aurora MySQL
La carga de trabajo de la base de datos se puede ver como lecturas y escrituras. Si comprende cuál es la carga de trabajo “normal” de una base de datos, podrá ajustar las consultas y el servidor de base de datos para adaptarlos a la demanda a medida que esta vaya cambiando. Existen varios motivos por los que el rendimiento puede cambiar, por lo que el primer paso es entender qué ha cambiado.
+ ¿Se ha realizado una actualización de una versión principal o secundaria?
Una actualización de la versión principal incluye cambios en el código del motor, especialmente en el optimizador, que pueden cambiar el plan de ejecución de las consultas. Al actualizar las versiones de la base de datos, especialmente las versiones principales, es muy importante analizar la carga de trabajo de la base de datos y ajustarla en consecuencia. Este ajuste puede implicar optimizar y reescribir las consultas o agregar y actualizar la configuración de los parámetros, en función de los resultados de las pruebas. Entender qué es lo que está causando ese efecto le permitirá empezar a centrarse en esa área específica.
Para obtener más información, consulte [What is new in MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html) y [Server and status variables and options added, deprecated, or removed in MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/added-deprecated-removed.html) en la documentación de MySQL y [Comparación entre Aurora MySQL versión 2 y Aurora MySQL versión 3](AuroraMySQL.Compare-v2-v3.md).
+ ¿Se ha producido un aumento en el procesamiento de datos (número de filas)?
+ ¿Hay más consultas ejecutándose simultáneamente?
+ ¿Hay cambios en el esquema o en la base de datos?
+ ¿Se han producido errores o correcciones en el código?
**Contents**
+ [Métricas de host de la instancia](#ams-workload-instance)
+ [Uso de la CPU](#ams-workload-cpu)
+ [Uso de memoria](#ams-workload-instance-memory)
+ [Network throughput](#ams-workload-network)
+ [Métricas de bases de datos](#ams-workload-db)
+ [Solución de problemas de uso de memoria de bases de datos Aurora MySQL](ams-workload-memory.md)
+ [Ejemplo 1: uso elevado y continuo de memoria](ams-workload-memory.md#ams-workload-memory.example1)
+ [Ejemplo 2: picos de memoria de transitorios](ams-workload-memory.md#ams-workload-memory.example2)
+ [Ejemplo 3: la memoria liberable cae continuamente y no se recupera](ams-workload-memory.md#ams-workload-memory.example3)
+ [Solución de problemas de memoria insuficiente de bases de datos Aurora MySQL](AuroraMySQLOOM.md)
## Métricas de host de la instancia
Supervise las métricas del host de la instancia, como la actividad de la CPU, la memoria y la red, para saber si se ha producido un cambio en la carga de trabajo. Existen dos conceptos principales para entender los cambios en la carga de trabajo:
+ Utilización: el uso de un dispositivo, como la CPU o el disco. Puede basarse en el tiempo o en la capacidad.
+ Basado en el tiempo: la cantidad de tiempo que un recurso está ocupado durante un período de observación determinado.
+ Basado en la capacidad: la cantidad de rendimiento que puede ofrecer un sistema o componente, expresado como porcentaje de su capacidad.
+ Saturación: hasta qué punto se requiere más trabajo de un recurso del que puede procesar. Cuando el uso basado en la capacidad alcanza el 100 %, el trabajo adicional no se puede procesar y debe ponerse en cola.
### Uso de la CPU
Puede utilizar las siguientes herramientas para identificar el uso y la saturación de la CPU:
+ CloudWatch proporciona la métrica `CPUUtilization`. Si llega al 100 %, la instancia está saturada. Sin embargo, las métricas de CloudWatch tienen un promedio de más de 1 minuto y carecen de granularidad.
Para obtener más información sobre las métricas de CloudWatch, consulte [Métricas de nivel de instancia para Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
+ El monitoreo mejorado proporciona métricas que devuelve el comando del sistema operativo `top`. Muestra los promedios de carga y los siguientes estados de la CPU, con una granularidad de 1 segundo:
+ `Idle (%)` = tiempo de inactividad
+ `IRQ (%)` = interrupciones de software
+ `Nice (%)` = tiempo nice para los procesos con una prioridad [niced](https://en.wikipedia.org/wiki/Nice_(Unix)).
+ `Steal (%)` = tiempo dedicado a atender a otros inquilinos (relacionado con la virtualización)
+ `System (%)` = tiempo del sistema
+ `User (%)` = tiempo de usuario
+ `Wait (%)` = espera de E/S
Para obtener más información acerca de las métricas de Supervisión mejorada, consulte [Métricas del sistema operativo para Aurora](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS).
### Uso de memoria
Si al sistema le falta memoria y el consumo de recursos está a punto de saturarse, debería haber un alto grado de errores de análisis de páginas, paginación, intercambio y falta de memoria.
Puede utilizar las siguientes herramientas para identificar el uso y la saturación de la memoria:
CloudWatch proporciona la métrica `FreeableMemory`, que muestra la cantidad de memoria que se puede recuperar vaciando algunas de las cachés del sistema operativo y la memoria libre actual.
Para obtener más información sobre las métricas de CloudWatch, consulte [Métricas de nivel de instancia para Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
El monitoreo mejorado proporciona las siguientes métricas que pueden ayudarle a identificar los problemas de uso de la memoria:
+ `Buffers (KB)`: la cantidad de memoria utilizada para almacenar en búfer solicitudes de E/S antes de escribir en el dispositivo de almacenamiento, en kilobytes.
+ `Cached (KB)`: la cantidad de memoria utilizada para almacenar en la caché las E/S basadas en el sistema de archivos.
+ `Free (KB)`: la cantidad de memoria no asignada, en kilobytes.
+ `Swap`: en caché, gratis y total.
Por ejemplo, si ve que la instancia de base de datos utiliza memoria `Swap`, la cantidad total de memoria para su carga de trabajo es mayor de la que la instancia tiene disponible actualmente. Le recomendamos aumentar el tamaño de la instancia de base de datos o ajustar la carga de trabajo para utilizar menos memoria.
Para obtener más información acerca de las métricas de Supervisión mejorada, consulte [Métricas del sistema operativo para Aurora](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS).
Para obtener información más detallada sobre el uso de Performance Schema y el esquema de `sys` para determinar qué conexiones y componentes utilizan memoria, consulte [Solución de problemas de uso de memoria de bases de datos Aurora MySQL](ams-workload-memory.md).
### Network throughput
CloudWatch proporciona las siguientes métricas para el rendimiento total de la red, todas con un promedio de más de 1 minuto:
+ `NetworkReceiveThroughput`: la cantidad de rendimiento de red que recibe de los clientes cada instancia en el clúster de base de datos de Aurora.
+ `NetworkTransmitThroughput`: el rendimiento de red que envía a los clientes cada instancia del clúster de base de datos de Aurora.
+ `NetworkThroughput`: el rendimiento de red que recibe de los clientes y transmite a ellos cada instancia en el clúster de base de datos de Aurora.
+ `StorageNetworkReceiveThroughput`: el rendimiento de red que se recibe del subsistema de almacenamiento de Aurora por cada instancia del clúster de base de datos.
+ `StorageNetworkTransmitThroughput`: el rendimiento de red que se envía al subsistema de almacenamiento de Aurora por cada instancia en el clúster de base de datos de Aurora.
+ `StorageNetworkThroughput`: el rendimiento de red que se recibe del subsistema de almacenamiento de Aurora y se envía a este por cada instancia en el clúster de base de datos de Aurora.
Para obtener más información sobre las métricas de CloudWatch, consulte [Métricas de nivel de instancia para Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
El monitoreo mejorado proporciona los gráficos de `network` recibidos (**RX**) y transmitidos (**TX**), con una granularidad de hasta 1 segundo.
Para obtener más información acerca de las métricas de Supervisión mejorada, consulte [Métricas del sistema operativo para Aurora](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS).
## Métricas de bases de datos
Examine las siguientes métricas de CloudWatch para ver si hay cambios en la carga de trabajo:
+ `BlockedTransactions`: número medio de transacciones de la base de datos que se bloquean cada segundo.
+ `BufferCacheHitRatio`: porcentaje de solicitudes que se responden desde la caché de búfer.
+ `CommitThroughput`: número medio de operaciones de confirmación por segundo.
+ `DatabaseConnections`: número de conexiones de red de cliente a la instancia de base de datos.
+ `Deadlocks`: número medio de interbloqueos en la base de datos por segundo.
+ `DMLThroughput`: número medio de inserciones, actualizaciones y eliminaciones por segundo.
+ `ResultSetCacheHitRatio`: porcentaje de solicitudes que se responden desde la caché de consultas.
+ `RollbackSegmentHistoryListLength`: registros redo que registran transacciones confirmadas con registros marcados para su eliminación.
+ `RowLockTime`: tiempo total dedicado a adquirir bloqueos de fila para tablas de InnoDB.
+ `SelectThroughput`: número medio de consultas de selección por segundo.
Para obtener más información sobre las métricas de CloudWatch, consulte [Métricas de nivel de instancia para Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
Tenga en cuenta las siguientes preguntas al examinar la carga de trabajo:
1. ¿Se han producido cambios recientes en la clase de la instancia de base de datos, por ejemplo, se ha reducido el tamaño de la instancia de 8xlarge a 4xlarge o se ha cambiado de db.r5 a db.r6?
1. ¿Puede crear un clon y reproducir el problema o solo ocurre en esa instancia?
1. ¿Se agotan los recursos del servidor? ¿La CPU o la memoria sufren un gran agotamiento? En caso afirmativo, esto podría significar que se requiere hardware adicional.
1. ¿Una o más consultas están tardando más tiempo?
1. ¿Los cambios se deben a una actualización, especialmente a una actualización de una versión principal? En caso afirmativo, compare las métricas previas y posteriores a la actualización.
1. ¿Hay cambios en la cantidad de instancias de base de datos de lector?
1. ¿Ha habilitado el registro general, de auditoría o binario? Para obtener más información, consulte [Registro de bases de datos Aurora MySQL](aurora-mysql-troubleshooting-logging.md).
1. ¿Ha habilitado, deshabilitado o cambiado el uso de la replicación de registros binarios (binlog)?
1. ¿Hay transacciones de larga duración que contengan un gran número de bloqueos de filas? Examine la longitud de la lista de historial (HLL) de InnoDB para ver si hay indicios de transacciones de larga duración.
Para obtener más información, consulte [La longitud de la lista de historial de InnoDB ha aumentado de forma significativa](proactive-insights.history-list.md) y la entrada del blog [Why is my SELECT query running slowly on my Amazon Aurora MySQL DB clúster?](https://repost.aws/knowledge-center/aurora-mysql-slow-select-query)
1. Si una HLL de gran tamaño se debe a una transacción de escritura, eso significa que los registros `UNDO` se están acumulando (no se limpian con regularidad). En una transacción de escritura de gran tamaño, esta acumulación puede aumentar rápidamente. En MySQL, `UNDO` se almacena en el [espacio de tabla SYSTEM](https://dev.mysql.com/doc/refman/5.7/en/innodb-system-tablespace.html). El espacio de tabla `SYSTEM` no se puede reducir. El registro `UNDO` puede hacer que el espacio de tabla `SYSTEM` aumente varios GB o incluso TB. Tras la purga, libere el espacio asignado realizando una copia de seguridad lógica (volcado) de los datos y, a continuación, importe el volcado a una nueva instancia de base de datos.
1. Si una HLL de gran tamaño se debe a una transacción de lectura (consulta de larga duración), eso puede significar que la consulta utiliza una gran cantidad de espacio temporal. Reinicie para liberar el espacio temporal. Examine las métricas de la base de datos de Información de rendimiento para ver si se ha producido algún cambio en la sección `Temp`, por ejemplo, `created_tmp_tables`. Para obtener más información, consulte [Monitoreo de la carga de base de datos con Performance Insights en Amazon Aurora](USER_PerfInsights.md).
1. ¿Se pueden dividir las transacciones de larga duración en otras más pequeñas que modifiquen menos filas?
1. ¿Se han producido cambios en las transacciones bloqueadas o han aumentado los interbloqueos? Examine las métricas de base de datos de Información de rendimiento para detectar cualquier cambio en las variables de estado en la sección `Locks`, como `innodb_row_lock_time`, ` innodb_row_lock_waits` y ` innodb_dead_locks`. Use intervalos de 1 o 5 minutos.
1. ¿Hay un aumento de los eventos de espera? Examine los eventos de espera y los tipos de espera de Información de rendimiento a intervalos de 1 o 5 minutos. Analice los principales eventos de espera y compruebe si están relacionados con los cambios en la carga de trabajo o con la contención de la base de datos. Por ejemplo, `buf_pool mutex` indica una contención del grupo de búferes. Para obtener más información, consulte [Ajuste de Aurora MySQL con eventos de espera](AuroraMySQL.Managing.Tuning.wait-events.md).
# Solución de problemas de uso de memoria de bases de datos Aurora MySQL
Si bien CloudWatch, Supervisión mejorada e Información de rendimiento proporcionan una visión general óptima del uso de la memoria en el sistema operativo, por ejemplo, la cantidad de memoria que utiliza el proceso de la base de datos, no permiten desglosar qué conexiones o componentes del motor podrían estar causando este uso de memoria.
Para solucionar este problema, puede utilizar Performance Schema y el esquema de `sys`. En Aurora MySQL versión 3, la instrumentación de memoria se habilita de forma predeterminada cuando se habilita Performance Schema. En Aurora MySQL versión 2, solo se habilita por defecto la instrumentación de memoria para el uso de memoria de Performance Schema. Para obtener información sobre las tablas disponibles en Performance Schema para realizar un seguimiento del uso de la memoria y habilitar la instrumentación de memoria de Performance Schema, consulte la [tablas de resumen de memoria](https://dev.mysql.com/doc/refman/8.3/en/performance-schema-memory-summary-tables.html) en la documentación de MySQL. Para obtener más información sobre el uso de Performance Schema con Información de rendimiento, consulte [Descripción general de Performance Schema para Información de rendimiento en Aurora MySQL](USER_PerfInsights.EnableMySQL.md).
Si bien se encuentra disponible información detallada en Performance Schema para realizar un seguimiento del uso actual de la memoria, el [esquema sys](https://dev.mysql.com/doc/refman/8.0/en/sys-schema.html) de MySQL tiene vistas en la parte superior de las tablas de Performance Schema que puede utilizar para identificar rápidamente dónde se utiliza la memoria.
En el esquema `sys`, están disponibles las siguientes vistas para realizar un seguimiento del uso de la memoria por conexión, componente y consulta.
| Visualización | Descripción |
| --- | --- |
| [memory\$1by\$1host\$1by\$1current\$1bytes](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-by-host-by-current-bytes.html) | Proporciona información sobre el uso de la memoria del motor por el host. Esto puede resultar útil para identificar qué servidores de aplicaciones o hosts de clientes consumen memoria. |
| [memory\$1by\$1thread\$1by\$1current\$1bytes](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-by-thread-by-current-bytes.html) | Proporciona información sobre el uso de la memoria del motor por ID de subproceso. El ID de subproceso en MySQL puede ser una conexión de cliente o un subproceso en segundo plano. Puede asignar ID de subprocesos a ID de conexión de MySQL mediante la vista [sys.processlist](https://dev.mysql.com/doc/refman/8.0/en/sys-processlist.html) o la tabla [performance\$1schema.threads](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-threads-table.html). |
| [memory\$1by\$1user\$1by\$1current\$1bytes](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-by-user-by-current-bytes.html) | Proporciona información sobre el uso de la memoria del motor por usuario. Esto puede resultar útil para identificar qué cuentas de usuario o clientes consumen memoria. |
| [memory\$1global\$1by\$1current\$1bytes](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-global-by-current-bytes.html) | Proporciona información sobre el uso de la memoria del motor por componente del motor. Esto puede resultar útil para identificar el uso de memoria global por parte de búferes o componentes del motor. Por ejemplo, es posible que vea el evento `memory/innodb/buf_buf_pool` del conjunto de búferes de InnoDB o el evento `memory/sql/Prepared_statement::main_mem_root` de las instrucciones preparadas. |
| [memory\$1global\$1total](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-global-total.html) | Proporciona una descripción general del uso total de memoria del que se ha hecho un seguimiento en el motor de base de datos. |
En Aurora MySQL versión 3.05 y versiones posteriores, también puede realizar un seguimiento del uso de memoria máximo mediante resumen de instrucciones en las [tablas de resumen de instrucciones de Performance Schema](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-summary-tables.html). Las tablas de resumen de instrucciones contienen resúmenes normalizados de instrucciones y estadísticas agregadas sobre su ejecución. La columna `MAX_TOTAL_MEMORY` puede ayudarle a identificar la memoria máxima utilizada por el resumen de consultas desde la última vez que se restablecieron las estadísticas o desde que se reinició la instancia de la base de datos. Esto puede resultar útil para identificar consultas específicas que podrían estar consumiendo mucha memoria.
**nota**
Performance Schema y el esquema `sys` muestran el uso actual de memoria en el servidor y los niveles máximos de memoria consumida por conexión y componente del motor. Como Performance Schema se mantiene en la memoria, la información se restablece cuando se reinicia la instancia de base de datos. Para mantener un historial a lo largo del tiempo, le recomendamos que configure la recuperación y el almacenamiento de estos datos fuera de Performance Schema.
**Topics**
+ [Ejemplo 1: uso elevado y continuo de memoria](#ams-workload-memory.example1)
+ [Ejemplo 2: picos de memoria de transitorios](#ams-workload-memory.example2)
+ [Ejemplo 3: la memoria liberable cae continuamente y no se recupera](#ams-workload-memory.example3)
## Ejemplo 1: uso elevado y continuo de memoria
Si observamos globalmente `FreeableMemory` en CloudWatch, podemos ver que el uso de memoria ha aumentado en gran medida a las 02:59 UTC del 26 de marzo de 2024.
![\[Gráfico de FreeableMemory que muestra un uso elevado de memoria.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/ams-freeable-memory.png)
Esto no nos muestra el panorama completo. Para determinar qué componente está consumiendo más memoria, puede iniciar sesión en la base de datos y ver `sys.memory_global_by_current_bytes`. Esta tabla contiene una lista de eventos de memoria de los que hace seguimiento MySQL, junto con información sobre la asignación de memoria por evento. Cada evento de seguimiento de memoria comienza con `memory/%`, seguido de otra información sobre el componente o la característica del motor al que está asociado el evento.
Por ejemplo, `memory/performance_schema/%` es para eventos de memoria relacionados con Performance Schema, `memory/innodb/%` es para InnoDB, etc. Para obtener información sobre las convenciones de nomenclatura de los eventos, consulte [Performance Schema Instrument Naming Conventions](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-instrument-naming.html) en la documentación de MySQL.
A partir de la siguiente consulta, podemos encontrar al probable culpable en función de `current_alloc`, pero también podemos ver muchos eventos de `memory/performance_schema/%`.
```
mysql> SELECT * FROM sys.memory_global_by_current_bytes LIMIT 10;
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc |
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| memory/sql/Prepared_statement::main_mem_root | 512817 | 4.91 GiB | 10.04 KiB | 512823 | 4.91 GiB | 10.04 KiB |
| memory/performance_schema/prepared_statements_instances | 252 | 488.25 MiB | 1.94 MiB | 252 | 488.25 MiB | 1.94 MiB |
| memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB |
| memory/performance_schema/events_errors_summary_by_thread_by_error | 1028 | 52.27 MiB | 52.06 KiB | 1028 | 52.27 MiB | 52.06 KiB |
| memory/performance_schema/events_statements_summary_by_thread_by_event_name | 4 | 47.25 MiB | 11.81 MiB | 4 | 47.25 MiB | 11.81 MiB |
| memory/performance_schema/events_statements_summary_by_digest | 1 | 40.28 MiB | 40.28 MiB | 1 | 40.28 MiB | 40.28 MiB |
| memory/performance_schema/memory_summary_by_thread_by_event_name | 4 | 31.64 MiB | 7.91 MiB | 4 | 31.64 MiB | 7.91 MiB |
| memory/innodb/memory | 15227 | 27.44 MiB | 1.85 KiB | 20619 | 33.33 MiB | 1.66 KiB |
| memory/sql/String::value | 74411 | 21.85 MiB | 307 bytes | 76867 | 25.54 MiB | 348 bytes |
| memory/sql/TABLE | 8381 | 21.03 MiB | 2.57 KiB | 8381 | 21.03 MiB | 2.57 KiB |
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
10 rows in set (0.02 sec)
```
Mencionamos anteriormente que Performance Schema se almacena en la memoria, lo que significa que también se realiza un seguimiento de ello en la instrumentación de memoria de `performance_schema`.
**nota**
Si observa que Performance Schema utiliza mucha memoria y quiere limitar su uso, puede ajustar los parámetros de la base de datos en función de sus necesidades. Para obtener más información, consulte [The Performance Schema memory-allocation model](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-memory-model.html) en la documentación de MySQL.
Para facilitar la lectura, puede volver a ejecutar la misma consulta pero excluir los eventos de Performance Schema. En el resultado se observa lo siguiente:
+ El elemento que consume más memoria es `memory/sql/Prepared_statement::main_mem_root`.
+ La columna `current_alloc` nos indica que MySQL tiene 4,91 GiB actualmente asignados a este evento.
+ `high_alloc column` nos indica que 4,91 GiB es el nivel máximo de `current_alloc` desde que se restablecieron las estadísticas por última vez o desde que se reinició el servidor. Esto significa que `memory/sql/Prepared_statement::main_mem_root` está en su valor más alto.
```
mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name NOT LIKE 'memory/performance_schema/%' LIMIT 10;
+-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc |
+-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| memory/sql/Prepared_statement::main_mem_root | 512817 | 4.91 GiB | 10.04 KiB | 512823 | 4.91 GiB | 10.04 KiB |
| memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB |
| memory/innodb/memory | 17096 | 31.68 MiB | 1.90 KiB | 22498 | 37.60 MiB | 1.71 KiB |
| memory/sql/String::value | 122277 | 27.94 MiB | 239 bytes | 124699 | 29.47 MiB | 247 bytes |
| memory/sql/TABLE | 9927 | 24.67 MiB | 2.55 KiB | 9929 | 24.68 MiB | 2.55 KiB |
| memory/innodb/lock0lock | 8888 | 19.71 MiB | 2.27 KiB | 8888 | 19.71 MiB | 2.27 KiB |
| memory/sql/Prepared_statement::infrastructure | 257623 | 16.24 MiB | 66 bytes | 257631 | 16.24 MiB | 66 bytes |
| memory/mysys/KEY_CACHE | 3 | 16.00 MiB | 5.33 MiB | 3 | 16.00 MiB | 5.33 MiB |
| memory/innodb/sync0arr | 3 | 7.03 MiB | 2.34 MiB | 3 | 7.03 MiB | 2.34 MiB |
| memory/sql/THD::main_mem_root | 815 | 6.56 MiB | 8.24 KiB | 849 | 7.19 MiB | 8.67 KiB |
+-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
10 rows in set (0.06 sec)
```
Por el nombre del evento, podemos decir que esta memoria se está utilizando para instrucciones preparadas. Si quiere ver qué conexiones utilizan esta memoria, puede consultar [memory\$1by\$1thread\$1by\$1current\$1bytes](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-by-thread-by-current-bytes.html).
En el siguiente ejemplo, cada conexión tiene aproximadamente 7 MiB asignados, con un nivel máximo de aproximadamente 6,29 MiB (`current_max_alloc`). Esto tiene sentido, ya que el ejemplo utiliza `sysbench` con 80 tablas y 800 conexiones con instrucciones preparadas. Si desea reducir el uso de memoria en este caso, puede optimizar el uso que hace su aplicación de las instrucciones preparadas para reducir el consumo de memoria.
```
mysql> SELECT * FROM sys.memory_by_thread_by_current_bytes;
+-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
| thread_id | user | current_count_used | current_allocated | current_avg_alloc | current_max_alloc | total_allocated |
+-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
| 46 | rdsadmin@localhost | 405 | 8.47 MiB | 21.42 KiB | 8.00 MiB | 155.86 MiB |
| 61 | reinvent@10.0.4.4 | 1749 | 6.72 MiB | 3.93 KiB | 6.29 MiB | 14.24 MiB |
| 101 | reinvent@10.0.4.4 | 1845 | 6.71 MiB | 3.72 KiB | 6.29 MiB | 14.50 MiB |
| 55 | reinvent@10.0.4.4 | 1674 | 6.68 MiB | 4.09 KiB | 6.29 MiB | 14.13 MiB |
| 57 | reinvent@10.0.4.4 | 1416 | 6.66 MiB | 4.82 KiB | 6.29 MiB | 13.52 MiB |
| 112 | reinvent@10.0.4.4 | 1759 | 6.66 MiB | 3.88 KiB | 6.29 MiB | 14.17 MiB |
| 66 | reinvent@10.0.4.4 | 1428 | 6.64 MiB | 4.76 KiB | 6.29 MiB | 13.47 MiB |
| 75 | reinvent@10.0.4.4 | 1389 | 6.62 MiB | 4.88 KiB | 6.29 MiB | 13.40 MiB |
| 116 | reinvent@10.0.4.4 | 1333 | 6.61 MiB | 5.08 KiB | 6.29 MiB | 13.21 MiB |
| 90 | reinvent@10.0.4.4 | 1448 | 6.59 MiB | 4.66 KiB | 6.29 MiB | 13.58 MiB |
| 98 | reinvent@10.0.4.4 | 1440 | 6.57 MiB | 4.67 KiB | 6.29 MiB | 13.52 MiB |
| 94 | reinvent@10.0.4.4 | 1433 | 6.57 MiB | 4.69 KiB | 6.29 MiB | 13.49 MiB |
| 62 | reinvent@10.0.4.4 | 1323 | 6.55 MiB | 5.07 KiB | 6.29 MiB | 13.48 MiB |
| 87 | reinvent@10.0.4.4 | 1323 | 6.55 MiB | 5.07 KiB | 6.29 MiB | 13.25 MiB |
| 99 | reinvent@10.0.4.4 | 1346 | 6.54 MiB | 4.98 KiB | 6.29 MiB | 13.24 MiB |
| 105 | reinvent@10.0.4.4 | 1347 | 6.54 MiB | 4.97 KiB | 6.29 MiB | 13.34 MiB |
| 73 | reinvent@10.0.4.4 | 1335 | 6.54 MiB | 5.02 KiB | 6.29 MiB | 13.23 MiB |
| 54 | reinvent@10.0.4.4 | 1510 | 6.53 MiB | 4.43 KiB | 6.29 MiB | 13.49 MiB |
. .
. .
. .
| 812 | reinvent@10.0.4.4 | 1259 | 6.38 MiB | 5.19 KiB | 6.29 MiB | 13.05 MiB |
| 214 | reinvent@10.0.4.4 | 1279 | 6.38 MiB | 5.10 KiB | 6.29 MiB | 12.90 MiB |
| 325 | reinvent@10.0.4.4 | 1254 | 6.38 MiB | 5.21 KiB | 6.29 MiB | 12.99 MiB |
| 705 | reinvent@10.0.4.4 | 1273 | 6.37 MiB | 5.13 KiB | 6.29 MiB | 13.03 MiB |
| 530 | reinvent@10.0.4.4 | 1268 | 6.37 MiB | 5.15 KiB | 6.29 MiB | 12.92 MiB |
| 307 | reinvent@10.0.4.4 | 1263 | 6.37 MiB | 5.17 KiB | 6.29 MiB | 12.87 MiB |
| 738 | reinvent@10.0.4.4 | 1260 | 6.37 MiB | 5.18 KiB | 6.29 MiB | 13.00 MiB |
| 819 | reinvent@10.0.4.4 | 1252 | 6.37 MiB | 5.21 KiB | 6.29 MiB | 13.01 MiB |
| 31 | innodb/srv_purge_thread | 17810 | 3.14 MiB | 184 bytes | 2.40 MiB | 205.69 MiB |
| 38 | rdsadmin@localhost | 599 | 1.76 MiB | 3.01 KiB | 1.00 MiB | 25.58 MiB |
| 1 | sql/main | 3756 | 1.32 MiB | 367 bytes | 355.78 KiB | 6.19 MiB |
| 854 | rdsadmin@localhost | 46 | 1.08 MiB | 23.98 KiB | 1.00 MiB | 5.10 MiB |
| 30 | innodb/clone_gtid_thread | 1596 | 573.14 KiB | 367 bytes | 254.91 KiB | 970.69 KiB |
| 40 | rdsadmin@localhost | 235 | 245.19 KiB | 1.04 KiB | 128.88 KiB | 808.64 KiB |
| 853 | rdsadmin@localhost | 96 | 94.63 KiB | 1009 bytes | 29.73 KiB | 422.45 KiB |
| 36 | rdsadmin@localhost | 33 | 36.29 KiB | 1.10 KiB | 16.08 KiB | 74.15 MiB |
| 33 | sql/event_scheduler | 3 | 16.27 KiB | 5.42 KiB | 16.04 KiB | 16.27 KiB |
| 35 | sql/compress_gtid_table | 8 | 14.20 KiB | 1.77 KiB | 8.05 KiB | 18.62 KiB |
| 25 | innodb/fts_optimize_thread | 12 | 1.86 KiB | 158 bytes | 648 bytes | 1.98 KiB |
| 23 | innodb/srv_master_thread | 11 | 1.23 KiB | 114 bytes | 361 bytes | 24.40 KiB |
| 24 | innodb/dict_stats_thread | 11 | 1.23 KiB | 114 bytes | 361 bytes | 1.35 KiB |
| 5 | innodb/io_read_thread | 1 | 144 bytes | 144 bytes | 144 bytes | 144 bytes |
| 6 | innodb/io_read_thread | 1 | 144 bytes | 144 bytes | 144 bytes | 144 bytes |
| 2 | sql/aws_oscar_log_level_monitor | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 4 | innodb/io_ibuf_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 7 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 8 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 9 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 10 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 11 | innodb/srv_lra_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 12 | innodb/srv_akp_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 18 | innodb/srv_lock_timeout_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 248 bytes |
| 19 | innodb/srv_error_monitor_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 20 | innodb/srv_monitor_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 21 | innodb/buf_resize_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 22 | innodb/btr_search_sys_toggle_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 32 | innodb/dict_persist_metadata_table_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 34 | sql/signal_handler | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
+-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
831 rows in set (2.48 sec)
```
Como se mencionó antes, el valor de ID de subproceso (`thd_id`) aquí puede hacer referencia a subprocesos en segundo plano del servidor o a conexiones de bases de datos. Si desea asignar valores de ID de subprocesos a ID de conexión a la base de datos, puede utilizar la tabla `performance_schema.threads` o la vista `sys.processlist`, donde `conn_id` es el ID de conexión.
```
mysql> SELECT thd_id,conn_id,user,db,command,state,time,last_wait FROM sys.processlist WHERE user='reinvent@10.0.4.4';
+--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+
| thd_id | conn_id | user | db | command | state | time | last_wait |
+--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+
| 590 | 562 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush |
| 578 | 550 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle |
| 579 | 551 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush |
| 580 | 552 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 581 | 553 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 582 | 554 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle |
| 583 | 555 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle |
| 584 | 556 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 585 | 557 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush |
| 586 | 558 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 587 | 559 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush |
. .
. .
. .
| 323 | 295 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle |
| 324 | 296 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 325 | 297 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush |
| 326 | 298 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 438 | 410 | reinvent@10.0.4.4 | sysbench | Execute | System lock | 0 | wait/lock/table/sql/handler |
| 280 | 252 | reinvent@10.0.4.4 | sysbench | Sleep | starting | 0 | wait/io/socket/sql/client_connection |
| 98 | 70 | reinvent@10.0.4.4 | sysbench | Query | freeing items | 0 | NULL |
+--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+
804 rows in set (5.51 sec)
```
Ahora detenemos la carga de trabajo de `sysbench`, lo que cierra las conexiones y libera memoria. Al volver a comprobar los eventos, podemos confirmar que la memoria se ha liberado, pero `high_alloc` nos sigue indicando cuál es el nivel máximo. La columna `high_alloc` puede resultar muy útil para identificar picos breves en el uso de memoria, cuando no se pueda identificar inmediatamente el uso de `current_alloc`, ya que muestra solo la memoria actualmente asignada.
```
mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name='memory/sql/Prepared_statement::main_mem_root' LIMIT 10;
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc |
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| memory/sql/Prepared_statement::main_mem_root | 17 | 253.80 KiB | 14.93 KiB | 512823 | 4.91 GiB | 10.04 KiB |
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
1 row in set (0.00 sec)
```
Si desea restablecer `high_alloc`, puede truncar las tablas de resumen de la memoria de `performance_schema`, pero esto restablece toda la instrumentación de la memoria. Para obtener más información, consulte [Performance Schema general table characteristics](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-table-characteristics.html) en la documentación de MySQL.
En el siguiente ejemplo, podemos observar que `high_alloc` se restablece tras el truncado.
```
mysql> TRUNCATE `performance_schema`.`memory_summary_global_by_event_name`;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name='memory/sql/Prepared_statement::main_mem_root' LIMIT 10;
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc |
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| memory/sql/Prepared_statement::main_mem_root | 17 | 253.80 KiB | 14.93 KiB | 17 | 253.80 KiB | 14.93 KiB |
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
1 row in set (0.00 sec)
```
## Ejemplo 2: picos de memoria de transitorios
Los picos breves en el uso de memoria son algo habitual en un servidor de base de datos. Puede tratarse de descensos periódicos de la memoria que se puede liberar y que son difíciles solucionar mediante `current_alloc` en `sys.memory_global_by_current_bytes`, ya que la memoria ya se ha liberado.
**nota**
Si se han restablecido las estadísticas de Performance Schema o se ha reiniciado la instancia de la base de datos, esta información no estará disponible en `sys` o p`erformance_schema`. Para conservar esta información, recomendamos que configure la recopilación de métricas externas.
El siguiente gráfico de la métrica de `os.memory.free` en Supervisión mejorada muestra breves picos de 7 segundos en el uso de la memoria. Supervisión mejorada permite supervisar a intervalos de tan solo un segundo, lo que resulta perfecto para detectar picos transitorios como estos.
![\[Gráfico que muestra picos transitorios de uso de memoria a lo largo del tiempo con un patrón periódico que indica posibles problemas de administración de la memoria.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/ams-free-memory-spikes.png)
Para ayudar a diagnosticar la causa del uso de memoria en este caso, podemos utilizar una combinación de `high_alloc` en las vistas de resumen de memoria de `sys` y las [tablas de resumen de instrucciones de Performance Schema](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-summary-tables.html) para tratar de identificar las sesiones y conexiones problemáticas.
Como era de esperar, dado que el uso de memoria no es elevado actualmente, no podemos detectar ningún infractor principal en la vista del esquema de `sys` bajo `current_alloc`.
```
mysql> SELECT * FROM sys.memory_global_by_current_bytes LIMIT 10;
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc |
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB |
| memory/innodb/os0event | 439372 | 60.34 MiB | 144 bytes | 439372 | 60.34 MiB | 144 bytes |
| memory/performance_schema/events_statements_summary_by_digest | 1 | 40.28 MiB | 40.28 MiB | 1 | 40.28 MiB | 40.28 MiB |
| memory/mysys/KEY_CACHE | 3 | 16.00 MiB | 5.33 MiB | 3 | 16.00 MiB | 5.33 MiB |
| memory/performance_schema/events_statements_history_long | 1 | 14.34 MiB | 14.34 MiB | 1 | 14.34 MiB | 14.34 MiB |
| memory/performance_schema/events_errors_summary_by_thread_by_error | 257 | 13.07 MiB | 52.06 KiB | 257 | 13.07 MiB | 52.06 KiB |
| memory/performance_schema/events_statements_summary_by_thread_by_event_name | 1 | 11.81 MiB | 11.81 MiB | 1 | 11.81 MiB | 11.81 MiB |
| memory/performance_schema/events_statements_summary_by_digest.digest_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB |
| memory/performance_schema/events_statements_history_long.digest_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB |
| memory/performance_schema/events_statements_history_long.sql_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB |
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
10 rows in set (0.01 sec)
```
Al ampliar la vista para ordenar por `high_alloc`, ahora podemos ver que el componente `memory/temptable/physical_ram` es muy buen candidato en este caso. En su nivel más alto, consumía 515,00 MiB.
Tal y como indica su nombre, `memory/temptable/physical_ram` instrumenta el uso de memoria del motor de almacenamiento `TEMP` en MySQL, que se introdujo en MySQL 8.0. Para obtener más información sobre cómo utiliza MySQL las tablas temporales, consulte [Internal temporary table use in MySQL](https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html) en la documentación de MySQL.
**nota**
En este ejemplo, estamos utilizando la vista `sys.x$memory_global_by_current_bytes`.
```
mysql> SELECT event_name, format_bytes(current_alloc) AS "currently allocated", sys.format_bytes(high_alloc) AS "high-water mark"
FROM sys.x$memory_global_by_current_bytes ORDER BY high_alloc DESC LIMIT 10;
+-----------------------------------------------------------------------------+---------------------+-----------------+
| event_name | currently allocated | high-water mark |
+-----------------------------------------------------------------------------+---------------------+-----------------+
| memory/temptable/physical_ram | 4.00 MiB | 515.00 MiB |
| memory/innodb/hash0hash | 79.07 MiB | 79.07 MiB |
| memory/innodb/os0event | 63.95 MiB | 63.95 MiB |
| memory/performance_schema/events_statements_summary_by_digest | 40.28 MiB | 40.28 MiB |
| memory/mysys/KEY_CACHE | 16.00 MiB | 16.00 MiB |
| memory/performance_schema/events_statements_history_long | 14.34 MiB | 14.34 MiB |
| memory/performance_schema/events_errors_summary_by_thread_by_error | 13.07 MiB | 13.07 MiB |
| memory/performance_schema/events_statements_summary_by_thread_by_event_name | 11.81 MiB | 11.81 MiB |
| memory/performance_schema/events_statements_summary_by_digest.digest_text | 9.77 MiB | 9.77 MiB |
| memory/performance_schema/events_statements_history_long.sql_text | 9.77 MiB | 9.77 MiB |
+-----------------------------------------------------------------------------+---------------------+-----------------+
10 rows in set (0.00 sec)
```
En [Ejemplo 1: uso elevado y continuo de memoria](#ams-workload-memory.example1), comprobamos el uso de memoria actual de cada conexión para determinar qué conexión es responsable del uso de la memoria en cuestión. En este ejemplo, la memoria ya está liberada, por lo que comprobar el uso de memoria de las conexiones actuales no resulta útil.
Para profundizar y encontrar las instrucciones, los usuarios y los host infractores, utilizamos Performance Schema. Performance Schema contiene varias tablas de resumen de instrucciones divididas en diferentes dimensiones, como el nombre del evento, el resumen de instrucciones, el host, el subproceso y el usuario. Cada vista le permitirá profundizar en dónde se ejecutan determinadas instrucciones y qué es lo que hacen. Esta sección se centra en `MAX_TOTAL_MEMORY`, pero puede encontrar más información sobre todas las columnas disponibles en la documentación de las [tablas de resumen de instrucciones de Performance Schema](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-summary-tables.html).
```
mysql> SHOW TABLES IN performance_schema LIKE 'events_statements_summary_%';
+------------------------------------------------------------+
| Tables_in_performance_schema (events_statements_summary_%) |
+------------------------------------------------------------+
| events_statements_summary_by_account_by_event_name |
| events_statements_summary_by_digest |
| events_statements_summary_by_host_by_event_name |
| events_statements_summary_by_program |
| events_statements_summary_by_thread_by_event_name |
| events_statements_summary_by_user_by_event_name |
| events_statements_summary_global_by_event_name |
+------------------------------------------------------------+
7 rows in set (0.00 sec)
```
En primer lugar, comprobamos `events_statements_summary_by_digest` para ver `MAX_TOTAL_MEMORY`.
A partir de esto, podemos ver lo siguiente:
+ La consulta con el resumen `20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a` parece ser una buena candidata para este uso de memoria. El valor de `MAX_TOTAL_MEMORY` es 537450710, que coincide con el nivel máximo que vimos para el evento de `memory/temptable/physical_ram` en `sys.x$memory_global_by_current_bytes`.
+ Se ha ejecutado cuatro veces (`COUNT_STAR`), la primera a las 04:08:34,943256 del 26 de marzo de 2024 y, la última, a las 04:43:06,998310 del 26 de marzo de 2024.
```
mysql> SELECT SCHEMA_NAME,DIGEST,COUNT_STAR,MAX_TOTAL_MEMORY,FIRST_SEEN,LAST_SEEN
FROM performance_schema.events_statements_summary_by_digest ORDER BY MAX_TOTAL_MEMORY DESC LIMIT 5;
+-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+
| SCHEMA_NAME | DIGEST | COUNT_STAR | MAX_TOTAL_MEMORY | FIRST_SEEN | LAST_SEEN |
+-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+
| sysbench | 20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a | 4 | 537450710 | 2024-03-26 04:08:34.943256 | 2024-03-26 04:43:06.998310 |
| NULL | f158282ea0313fefd0a4778f6e9b92fc7d1e839af59ebd8c5eea35e12732c45d | 4 | 3636413 | 2024-03-26 04:29:32.712348 | 2024-03-26 04:36:26.269329 |
| NULL | 0046bc5f642c586b8a9afd6ce1ab70612dc5b1fd2408fa8677f370c1b0ca3213 | 2 | 3459965 | 2024-03-26 04:31:37.674008 | 2024-03-26 04:32:09.410718 |
| NULL | 8924f01bba3c55324701716c7b50071a60b9ceaf17108c71fd064c20c4ab14db | 1 | 3290981 | 2024-03-26 04:31:49.751506 | 2024-03-26 04:31:49.751506 |
| NULL | 90142bbcb50a744fcec03a1aa336b2169761597ea06d85c7f6ab03b5a4e1d841 | 1 | 3131729 | 2024-03-26 04:15:09.719557 | 2024-03-26 04:15:09.719557 |
+-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+
5 rows in set (0.00 sec)
```
Ahora que conocemos el resumen infractor, podemos obtener más detalles, como el texto de la consulta, el usuario que la ejecutó y dónde se ejecutó. Según el texto del resumen devuelto, podemos ver que se trata de una expresión común de tabla (CTE) que crea cuatro tablas temporales y realiza cuatro análisis de tablas, lo que resulta muy ineficiente.
```
mysql> SELECT SCHEMA_NAME,DIGEST_TEXT,QUERY_SAMPLE_TEXT,MAX_TOTAL_MEMORY,SUM_ROWS_SENT,SUM_ROWS_EXAMINED,SUM_CREATED_TMP_TABLES,SUM_NO_INDEX_USED
FROM performance_schema.events_statements_summary_by_digest
WHERE DIGEST='20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a'\G;
*************************** 1. row ***************************
SCHEMA_NAME: sysbench
DIGEST_TEXT: WITH RECURSIVE `cte` ( `n` ) AS ( SELECT ? FROM `sbtest1` UNION ALL SELECT `id` + ? FROM `sbtest1` ) SELECT * FROM `cte`
QUERY_SAMPLE_TEXT: WITH RECURSIVE cte (n) AS ( SELECT 1 from sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte
MAX_TOTAL_MEMORY: 537450710
SUM_ROWS_SENT: 80000000
SUM_ROWS_EXAMINED: 80000000
SUM_CREATED_TMP_TABLES: 4
SUM_NO_INDEX_USED: 4
1 row in set (0.01 sec)
```
Para obtener más información sobre la tabla `events_statements_summary_by_digest` y otras tablas de resumen de instrucciones de Performance Schema, consulte [Statement summary tables](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-summary-tables.html) en la documentación de MySQL.
También puede ejecutar una instrucción [EXPLAIN](https://dev.mysql.com/doc/refman/8.0/en/explain.html) o [EXPLAIN ANALYZE](https://dev.mysql.com/doc/refman/8.0/en/explain.html#explain-analyze) para obtener más detalles.
**nota**
`EXPLAIN ANALYZE` puede aportar más información que `EXPLAIN`, pero también ejecuta la consulta, así que debe tener cuidado.
```
-- EXPLAIN
mysql> EXPLAIN WITH RECURSIVE cte (n) AS (SELECT 1 FROM sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte;
+----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+
| 1 | PRIMARY | | NULL | ALL | NULL | NULL | NULL | NULL | 19221520 | 100.00 | NULL |
| 2 | DERIVED | sbtest1 | NULL | index | NULL | k_1 | 4 | NULL | 9610760 | 100.00 | Using index |
| 3 | UNION | sbtest1 | NULL | index | NULL | k_1 | 4 | NULL | 9610760 | 100.00 | Using index |
+----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+
3 rows in set, 1 warning (0.00 sec)
-- EXPLAIN format=tree
mysql> EXPLAIN format=tree WITH RECURSIVE cte (n) AS (SELECT 1 FROM sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte\G;
*************************** 1. row ***************************
EXPLAIN: -> Table scan on cte (cost=4.11e+6..4.35e+6 rows=19.2e+6)
-> Materialize union CTE cte (cost=4.11e+6..4.11e+6 rows=19.2e+6)
-> Index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6)
-> Index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6)
1 row in set (0.00 sec)
-- EXPLAIN ANALYZE
mysql> EXPLAIN ANALYZE WITH RECURSIVE cte (n) AS (SELECT 1 from sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte\G;
*************************** 1. row ***************************
EXPLAIN: -> Table scan on cte (cost=4.11e+6..4.35e+6 rows=19.2e+6) (actual time=6666..9201 rows=20e+6 loops=1)
-> Materialize union CTE cte (cost=4.11e+6..4.11e+6 rows=19.2e+6) (actual time=6666..6666 rows=20e+6 loops=1)
-> Covering index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) (actual time=0.0365..2006 rows=10e+6 loops=1)
-> Covering index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) (actual time=0.0311..2494 rows=10e+6 loops=1)
1 row in set (10.53 sec)
```
Pero, ¿quién lo ha ejecutado? Podemos ver en Performance Schema que el usuario `destructive_operator` tenía un `MAX_TOTAL_MEMORY` de 537450710, lo que de nuevo coincide con los resultados anteriores.
**nota**
Performance Schema se almacena en la memoria, por lo que no se debe confiar en él como la única fuente de auditoría. Si necesita mantener un historial de las instrucciones ejecutadas y qué usuarios las ejecutan, le recomendamos que habilite [Aurora Advanced Auditing](AuroraMySQL.Auditing.md). Si también necesita mantener información sobre el uso de la memoria, le recomendamos que configure la supervisión para exportar y almacenar estos valores.
```
mysql> SELECT USER,EVENT_NAME,COUNT_STAR,MAX_TOTAL_MEMORY FROM performance_schema.events_statements_summary_by_user_by_event_name
ORDER BY MAX_CONTROLLED_MEMORY DESC LIMIT 5;
+----------------------+---------------------------+------------+------------------+
| USER | EVENT_NAME | COUNT_STAR | MAX_TOTAL_MEMORY |
+----------------------+---------------------------+------------+------------------+
| destructive_operator | statement/sql/select | 4 | 537450710 |
| rdsadmin | statement/sql/select | 4172 | 3290981 |
| rdsadmin | statement/sql/show_tables | 2 | 3615821 |
| rdsadmin | statement/sql/show_fields | 2 | 3459965 |
| rdsadmin | statement/sql/show_status | 75 | 1914976 |
+----------------------+---------------------------+------------+------------------+
5 rows in set (0.00 sec)
mysql> SELECT HOST,EVENT_NAME,COUNT_STAR,MAX_TOTAL_MEMORY FROM performance_schema.events_statements_summary_by_host_by_event_name
WHERE HOST != 'localhost' AND COUNT_STAR>0 ORDER BY MAX_CONTROLLED_MEMORY DESC LIMIT 5;
+------------+----------------------+------------+------------------+
| HOST | EVENT_NAME | COUNT_STAR | MAX_TOTAL_MEMORY |
+------------+----------------------+------------+------------------+
| 10.0.8.231 | statement/sql/select | 4 | 537450710 |
+------------+----------------------+------------+------------------+
1 row in set (0.00 sec)
```
## Ejemplo 3: la memoria liberable cae continuamente y no se recupera
El motor de base de datos InnoDB emplea una variedad de eventos de seguimiento de memoria especializados para diferentes componentes. Estos eventos específicos permiten un seguimiento detallado del uso de la memoria en los principales subsistemas de InnoDB, por ejemplo:
+ `memory/innodb/buf0buf`: dedicado a supervisar las asignaciones de memoria para el grupo de búferes de InnoDB.
+ `memory/innodb/ibuf0ibuf`: realiza un seguimiento específico de los cambios de memoria relacionados con el búfer de cambios de InnoDB.
Para identificar los principales consumidores de memoria, podemos consultar `sys.memory_global_by_current_bytes`:
```
mysql> SELECT event_name,current_alloc FROM sys.memory_global_by_current_bytes LIMIT 10;
+-----------------------------------------------------------------+---------------+
| event_name | current_alloc |
+-----------------------------------------------------------------+---------------+
| memory/innodb/memory | 5.28 GiB |
| memory/performance_schema/table_io_waits_summary_by_index_usage | 495.00 MiB |
| memory/performance_schema/table_shares | 488.00 MiB |
| memory/sql/TABLE_SHARE::mem_root | 388.95 MiB |
| memory/innodb/std | 226.88 MiB |
| memory/innodb/fil0fil | 198.49 MiB |
| memory/sql/binlog_io_cache | 128.00 MiB |
| memory/innodb/mem0mem | 96.82 MiB |
| memory/innodb/dict0dict | 96.76 MiB |
| memory/performance_schema/rwlock_instances | 88.00 MiB |
+-----------------------------------------------------------------+---------------+
10 rows in set (0.00 sec)
```
Los resultados muestran que `memory/innodb/memory` es el principal consumidor, ya que utiliza 5,28 GiB de la memoria asignada actualmente. Este evento sirve como categoría para las asignaciones de memoria entre varios componentes de InnoDB no asociados a eventos de espera más específicos, como los `memory/innodb/buf0buf` mencionados anteriormente.
Una vez establecido que los componentes de InnoDB son los principales consumidores de memoria, podemos profundizar en los detalles con el siguiente comando de MySQL:
```
SHOW ENGINE INNODB STATUS \G;
```
El comando [SHOW ENGINE INNODB STATUS](https://dev.mysql.com/doc/refman/8.4/en/show-engine.html) proporciona un informe de estado completo del motor de almacenamiento de InnoDB, que incluye estadísticas detalladas de uso de memoria de los diferentes componentes de InnoDB. Puede ayudar a identificar qué estructuras u operaciones específicas de InnoDB consumen más memoria. Para obtener información, consulte [InnoDB in-memory structures](https://dev.mysql.com/doc/refman/8.0/en/innodb-in-memory-structures.html) en la documentación de MySQL.
Al analizar la sección `BUFFER POOL AND MEMORY` del informe de estado de InnoDB, vemos que se asignan 5 051 647 748 bytes (4,7 GiB) a la [caché de objetos del diccionario](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-object-cache.html), que representa el 89 % de la memoria rastreada por `memory/innodb/memory`.
```
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 0
Dictionary memory allocated 5051647748
Buffer pool size 170512
Free buffers 142568
Database pages 27944
Old database pages 10354
Modified db pages 6
Pending reads 0
```
La caché de objetos del diccionario es una caché global compartida que almacena en la memoria los objetos del diccionario de datos a los que se ha accedido anteriormente para permitir la reutilización de los objetos y mejorar el rendimiento. La elevada asignación de memoria a la caché de objetos del diccionario sugiere que hay una gran cantidad de objetos de base de datos en la caché del diccionario de datos.
Ahora que sabemos que la caché del diccionario de datos es un consumidor principal, procedemos a inspeccionar la caché del diccionario de datos para ver si hay tablas abiertas. Para encontrar el número de tablas en la caché de definiciones de tablas, consulte la variable de estado global [open\$1table\$1definitions](https://dev.mysql.com/doc/refman/8.4/en/server-status-variables.html#statvar_Open_table_definitions).
```
mysql> show global status like 'open_table_definitions';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| Open_table_definitions | 20000 |
+------------------------+-------+
1 row in set (0.00 sec)
```
Para obtener más información, consulte [How MySQL Opens and Closes Tables](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html) en la documentación de MySQL.
Puede limitar el número de definiciones de tablas en la caché del diccionario de datos limitando el parámetro `table_definition_cache` en el clúster de base de datos o en el grupo de parámetros de la instancia de base de datos. Para Aurora MySQL, este valor sirve como límite flexible para el número de tablas en la caché de definición de tablas. El valor predeterminado depende de la clase de instancia y se establece de la siguiente manera:
```
LEAST({DBInstanceClassMemory/393040}, 20000)
```
Cuando el número de tablas supera el límite de `table_definition_cache`, el mecanismo utilizado menos recientemente (LRU) expulsa y elimina las tablas de la memoria caché. Sin embargo, las tablas involucradas en relaciones de clave externa no se incluyen en la lista LRU, lo que impide su eliminación.
En nuestro escenario actual, ejecutamos [FLUSH TABLES](https://dev.mysql.com/doc/refman/8.4/en/flush.html) para borrar la caché de definiciones de tablas. Esta acción provoca una caída significativa de la variable de estado global [Open\$1table\$1definitions](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Open_table_definitions), de 20 000 a 12, tal como se muestra a continuación:
```
mysql> show global status like 'open_table_definitions';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| Open_table_definitions | 12 |
+------------------------+-------+
1 row in set (0.00 sec)
```
A pesar de esta reducción, observamos que la asignación de memoria para `memory/innodb/memory` sigue siendo alta, de 5,18 GiB, y la memoria del diccionario asignada también permanece sin cambios. Esto queda patente en los siguientes resultados de la consulta:
```
mysql> SELECT event_name,current_alloc FROM sys.memory_global_by_current_bytes LIMIT 10;
+-----------------------------------------------------------------+---------------+
| event_name | current_alloc |
+-----------------------------------------------------------------+---------------+
| memory/innodb/memory | 5.18 GiB |
| memory/performance_schema/table_io_waits_summary_by_index_usage | 495.00 MiB |
| memory/performance_schema/table_shares | 488.00 MiB |
| memory/sql/TABLE_SHARE::mem_root | 388.95 MiB |
| memory/innodb/std | 226.88 MiB |
| memory/innodb/fil0fil | 198.49 MiB |
| memory/sql/binlog_io_cache | 128.00 MiB |
| memory/innodb/mem0mem | 96.82 MiB |
| memory/innodb/dict0dict | 96.76 MiB |
| memory/performance_schema/rwlock_instances | 88.00 MiB |
+-----------------------------------------------------------------+---------------+
10 rows in set (0.00 sec)
```
```
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 0
Dictionary memory allocated 5001599639
Buffer pool size 170512
Free buffers 142568
Database pages 27944
Old database pages 10354
Modified db pages 6
Pending reads 0
```
Este elevado uso de memoria de forma persistente se puede atribuir a las tablas implicadas en relaciones de claves externas. Estas tablas no se incluyen en la lista LRU para su eliminación, lo que explica por qué la asignación de memoria sigue siendo alta incluso después de vaciar la caché de definiciones de tablas.
Para solucionar este problema:
1. Revise y optimice el esquema de su base de datos, especialmente las relaciones de claves externas.
1. Considere la posibilidad de cambiar a una clase de instancia de base de datos más grande que tenga más memoria para acomodar los objetos de diccionario.
Si sigue estos pasos y comprende los patrones de asignación de memoria, podrá administrar mejor el uso de la memoria en su instancia de base de datos de Aurora MySQL y evitar posibles problemas de rendimiento debido a la presión sobre la memoria.
# Solución de problemas de memoria insuficiente de bases de datos Aurora MySQL
El parámetro de nivel de instancia `aurora_oom_response` de Aurora MySQL puede permitir que la instancia de base de datos monitoricela memoria del sistema y calcule la memoria consumida por diferentes declaraciones y conexiones. Si el sistema funciona con poca memoria, puede realizar una lista de acciones para intentar liberar dicha memoria. Lo hace en un intento de evitar un reinicio de la base de datos debido a problemas de falta de memoria (OOM). El parámetro de nivel de instancia toma una cadena de acciones separadas por comas que una instancia de base de datos realiza cuando el nivel de memoria es bajo. El parámetro `aurora_oom_response` se admite en las versiones 2 y 3 de Aurora MySQL.
Se pueden usar los siguientes valores y combinaciones de ellos para el parámetro `aurora_oom_response`. La existencia de una cadena vacía significa que no se ha tomado ninguna acción y desactiva de forma efectiva la característica, lo que hace que la base de datos sea propensa a que se reinicie debido a OOM.
+ `decline`: rechaza nuevas consultas una vez que la instancia de base de datos tiene poca memoria.
+ `kill_connect`: cierra las conexiones de bases de datos que consumen una gran cantidad de memoria y finaliza las transacciones actuales y las instrucciones del lenguaje de definición de datos (DDL). Esta respuesta no se admite en la versión 2 de Aurora MySQL.
Para obtener más información, consulte [KILL statement](https://dev.mysql.com/doc/refman/8.0/en/kill.html) en la documentación de MySQL.
+ `kill_query`: finaliza las consultas en orden descendente de consumo de memoria hasta que la memoria de la instancia esté por encima del umbral bajo. Las instrucciones DDL no finalizan.
Para obtener más información, consulte [KILL statement](https://dev.mysql.com/doc/refman/8.0/en/kill.html) en la documentación de MySQL.
+ `print`: solo imprime las consultas que consumen una gran cantidad de memoria.
+ `tune`: ajusta las cachés de tablas internas para liberar memoria en el sistema. Aurora MySQL reduce la memoria utilizada para cachés, por ejemplo, `table_open_cache` y `table_definition_cache`, en condiciones de poca memoria. Finalmente, Aurora MySQL restablece su uso de memoria a la normalidad cuando el sistema deja de tener poca memoria.
Para obtener más información, consulte [table\$1open\$1cache](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_table_open_cache) y [table\$1definition\$1cache](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_table_definition_cache) en la documentación de MySQL.
+ `tune_buffer_pool`: reduce el tamaño del grupo de búferes para liberar parte de la memoria y ponerla a disposición del servidor de base de datos para procesar las conexiones. Este respuestas se admite para la versión 3.06 y versiones posteriores de Aurora MySQL.
Debe emparejar `tune_buffer_pool` con `kill_query` o `kill_connect` en el valor del parámetro `aurora_oom_response`. De lo contrario, no se redimensionará el grupo de búferes, ni siquiera si incluye `tune_buffer_pool` en el valor del parámetro.
En las versiones de Aurora MySQL anteriores a la 3.06, para las clases de instancias de base de datos con una memoria inferior o igual a 4 GiB, cuando a la instancia le falta memoria, las acciones predeterminadas incluyen `print`, `tune`, `decline` y `kill_query`. Para las clases de instancia de base de datos con memoria superior a 4 GiB, el valor del parámetro está vacío de manera predeterminada (deshabilitado).
En la versión 3.06 y posteriores de Aurora MySQL, para las clases de instancias de base de datos con una memoria inferior o igual a 4 GiB, Aurora MySQL también cierra las conexiones que consumen más memoria (`kill_connect`). Para las clases de instancia de base de datos con memoria superior a 4 GiB, el valor del parámetro es `print` de forma predeterminada.
En la versión 3.09 de Aurora MySQL y posteriores, para las clases de instancia de base de datos con memoria superior a 4 GiB, el valor del parámetro es `print,decline,kill_connect` de forma predeterminada.
Si se encuentra con frecuencia con problemas de falta de memoria, puede monitorear el uso de la memoria mediante [tablas de resumen de memoria](https://dev.mysql.com/doc/refman/8.3/en/performance-schema-memory-summary-tables.html) cuando `performance_schema` está habilitado.
Para ver las métricas de Amazon CloudWatch relacionadas con la OOM, consulte [Métricas de nivel de instancia para Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances). Para ver las variables de estado globales relacionadas con la OOM, consulte [Variables de estado globales de Aurora MySQL](AuroraMySQL.Reference.GlobalStatusVars.md).
# Registro de bases de datos Aurora MySQL
Los registros de Aurora MySQL proporcionan información esencial sobre la actividad y los errores de la base de datos. Al habilitar estos registros, puede identificar y solucionar problemas, comprender el rendimiento de la base de datos y auditar la actividad de la base de datos. Le recomendamos que habilite estos registros para todas las instancias de base de datos de Aurora MySQL para garantizar un rendimiento y una disponibilidad óptimos de las bases de datos. Se pueden habilitar los siguientes tipos de registros. Cada registro contiene información específica que puede permitir descubrir el impacto en el procesamiento de las bases de datos.
+ Error: Aurora MySQL solo escribe en el registro de errores durante el inicio, el cierre y cuando encuentra errores. Una instancia de base de datos puede pasar horas o días sin que se escriban nuevas entradas en el registro de errores. Si no hay entradas recientes, se debe a que el servidor no ha encontrado ningún error que genere una entrada en el registro. El registro de errores está habilitado de forma predeterminada. Para obtener más información, consulte [Registros de errores de Aurora MySQL](USER_LogAccess.MySQL.LogFileSize.md#USER_LogAccess.MySQL.Errorlog).
+ General: el registro general proporciona información detallada sobre la actividad de la base de datos, incluidas todas las instrucciones SQL que ejecuta el motor de base de datos. Para obtener más información sobre cómo habilitar el registro general y configurar los parámetros de registro, consulte [Registros generales y de consultas lentas de Aurora MySQL](USER_LogAccess.MySQL.LogFileSize.md#USER_LogAccess.MySQL.Generallog) y [The general query log](https://dev.mysql.com/doc/refman/8.0/en/query-log.html) en la documentación de MySQL.
**nota**
Los registros generales pueden llegar a ser muy grandes y consumir espacio de almacenamiento. Para obtener más información, consulte [Rotación y retención de registros en Aurora MySQL](USER_LogAccess.MySQL.LogFileSize.md#USER_LogAccess.AMS.LogFileSize.retention).
+ Consulta lenta: el registro de consultas lentas consta de instrucciones SQL que tardan en ejecutarse un tiempo en segundos superior al que está configurado en [long\$1query\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_long_query_time) y que requieren al menos el número de filas que está configurado en [min\$1examined\$1row\$1limit](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_min_examined_row_limit) para examinarlas. Puede utilizar el registro de consultas lentas para buscar consultas que tarden mucho en ejecutarse y que, por lo tanto, sean candidatas para la optimización.
El valor de predeterminado para `long_query_time` es de 10 segundos. Le recomendamos que comience con un valor alto para identificar las consultas más lentas y, a continuación, vaya bajando para ajustarlas con mayor precisión.
También puede utilizar parámetros relacionados, como `log_slow_admin_statements` y `log_queries_not_using_indexes`. Compare `rows_examined` con `rows_returned`. Si `rows_examined` es mucho mayor que `rows_returned`, esas consultas podrían estar creando un bloqueo.
En la versión 3 de Aurora MySQL, puede habilitar `log_slow_extra` para obtener más detalles. Para obtener más información, consulte [Slow query log contents](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html#slow-query-log-contents) en la documentación de MySQL. También puede modificar `long_query_time` para la sesión para depurar la ejecución de consultas de forma interactiva, lo que resulta especialmente útil si `log_slow_extra` está habilitado de forma global.
Para obtener más información sobre cómo habilitar el registro de consultas lentas y configurar los parámetros de registro, consulte [Registros generales y de consultas lentas de Aurora MySQL](USER_LogAccess.MySQL.LogFileSize.md#USER_LogAccess.MySQL.Generallog) y [The slow query log](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html) en la documentación de MySQL.
+ Auditoría: el registro de auditoría monitorea y registra la actividad de la base de datos. El registro de auditoría para Aurora MySQL se llama auditoría avanzada. Para habilitar la auditoría avanzada, hay que establecer ciertos parámetros del clúster de base de datos. Para obtener más información, consulte [Uso de auditorías avanzadas con un clúster de base de datos de Amazon Aurora MySQL](AuroraMySQL.Auditing.md).
+ Binario: el registro binario (binlog) contiene eventos que describen los cambios en la base de datos, como las operaciones de creación de tablas y los cambios en los datos de las tablas. También contiene eventos para instrucciones que podrían haber realizado cambios (por ejemplo, un [DELETE](https://dev.mysql.com/doc/refman/8.0/en/delete.html) que no se corresponde con ninguna fila), a menos que se utilice el registro basado en filas. El registro binario también contiene información sobre el tiempo que tardó cada instrucción en actualizar los datos.
Al ejecutar un servidor con el registro binario habilitado, el rendimiento es un poco más lento. Sin embargo, las ventajas del registro binario, al permitirle configurar la replicación y las operaciones de restauración, por lo general, compensan esta pequeña disminución del rendimiento.
**nota**
Aurora MySQL no requiere el registro binario para las operaciones de restauración.
Para obtener más información sobre cómo habilitar el registro binario y configurar el formato binlog, consulte [Configuración del registro binario de Aurora MySQL para bases de datos Single-AZ](USER_LogAccess.MySQL.BinaryFormat.md) y [The binary log](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) en la documentación de MySQL.
Puede publicar registros de errores, generales, de consultas lentas y de auditoría en Registros de Amazon CloudWatch. Para obtener más información, consulte [Publicación de registros de base de datos en registros de Amazon Cloudwatch](USER_LogAccess.Procedural.UploadtoCloudWatch.md).
Otra herramienta útil para resumir archivos de registro lentos, generales y binarios es [pt-query-digest](https://docs.percona.com/percona-toolkit/pt-query-digest.html).
# Solución de problemas de conexión para bases de datos Aurora MySQL
Garantizar una conectividad fiable entre sus aplicaciones y su instancia de base de datos de RDS es fundamental para el buen funcionamiento de sus cargas de trabajo. Sin embargo, los problemas de conectividad pueden surgir como consecuencia de varios factores, como las configuraciones de la red, los problemas de autenticación o las limitaciones de recursos. El objetivo de esta guía es proporcionar un enfoque integral para solucionar problemas de conectividad con Aurora MySQL.
**Contents**
+ [Identificación de problemas de conectividad de bases de datos para Aurora MySQL](#mysql-dbconn-identify)
+ [Recopilación de datos sobre problemas de conectividad para Aurora MySQL](#mysql-dbconn-gather)
+ [Supervisión de las conexiones de bases de datos para Aurora MySQL](#mysql-dbconn-monitor)
+ [Supervisión adicional para Aurora MySQL](#mysql-dbconn-monitor-ams)
+ [Códigos de error de conectividad para Aurora MySQL](#mysql-dbconn-errors)
+ [Recomendaciones de ajuste de parámetros para Aurora MySQL](#mysql-dbconn-params)
+ [Ejemplos de solución de problemas de conexión de bases de datos para Aurora MySQL](#mysql-dbconn-examples)
+ [Ejemplo 1: Solución de problemas de intentos de conexión fallidos](#mysql-dbconn-example1)
+ [Ejemplo 2: Solución de problemas de desconexiones anómalas de un cliente](#mysql-dbconn-example2)
+ [Ejemplo 3: Solución de problemas de intentos de conexión erróneos de IAM](#mysql-dbconn-example3)
## Identificación de problemas de conectividad de bases de datos para Aurora MySQL
Identificar la categoría específica del problema de conectividad puede ayudar a reducir las posibles causas y guiar el proceso de solución de problemas. Cada categoría puede requerir enfoques y técnicas diferentes para el diagnóstico y la resolución. Los problemas de conectividad de las bases de datos se pueden clasificar, en términos generales, en las siguientes categorías.
**Excepciones y errores de conexión**
Los errores de conexión y las excepciones se pueden producir por varios motivos, como cadenas de conexión incorrectas, errores de autenticación, interrupciones de la red o problemas con el servidor de la base de datos. Algunas de las causas son parámetros de conexión mal configurados, credenciales no válidas, interrupciones de la red o bloqueos o reinicios del servidor de base de datos. Los grupos de seguridad mal configurados, la configuración de la nube privada virtual (VPC), las listas de control de acceso (ACL) a la red y las tablas de enrutamiento asociadas a las subredes también pueden provocar problemas de conexión.
**Límites de conexión alcanzado**
Este problema se produce cuando el número de conexiones simultáneas al servidor de base de datos supera el límite máximo permitido. Los servidores de bases de datos suelen tener un límite de conexión máximo configurable definido por el parámetro max\$1connections en los clústeres y los grupos de parámetros de instancia. Al imponer un límite de conexión, el servidor de base de datos se asegura de que dispone de recursos suficientes (por ejemplo, memoria, CPU y controladores de archivos) para administrar las conexiones existentes de forma eficaz y ofrecer un rendimiento aceptable. Las causas pueden incluir pérdidas de conexión en la aplicación, una agrupación de conexiones ineficiente o un aumento inesperado de las solicitudes de conexión.
**Tiempos de espera de conexión**
Los tiempos de espera de conexión se producen cuando la aplicación cliente no puede establecer una conexión con el servidor de base de datos dentro de un periodo de tiempo de espera especificado. Algunas de las causas más comunes son problemas de red, sobrecarga del servidor, reglas de firewall y ajustes de conexión mal configurados.
**Tiempos de espera de inactividad de conexión**
El servidor de la base de datos puede cerrar automáticamente las conexiones inactivas que permanecen inactivas durante un periodo prolongado para conservar los recursos. Este tiempo de espera suele configurarse mediante la tecla `wait_timeout` y `interactive_timeout parameters`, y debe ajustarse en función de los patrones de uso de la conexión de la aplicación. Algunas causas son que la lógica de la aplicación deje las conexiones inactivas durante periodos prolongados o una administración inadecuada de las conexiones.
**Desconexión intermitente de las conexiones existentes**
Esta clase de errores se refiere a un escenario en el que las conexiones establecidas entre una aplicación cliente y la base de datos se interrumpen inesperadamente o se desconectan a intervalos irregulares, a pesar de estar activas y en uso. Estas desconexiones se producen de forma intermitente, lo que significa que se producen a intervalos irregulares y de forma no consistente. Estas pueden ser algunas de las causas:
+ Problemas con el servidor de bases de datos, como reinicios o conmutaciones por error
+ Administración inadecuada de la conexión de la aplicación
+ Problemas de equilibrio de carga y proxy
+ Inestabilidad de la red
+ Problemas con componentes o middleware de terceros involucrados en la ruta de conexión
+ Tiempos de espera de ejecución de la consulta
+ Restricciones de recursos en el servidor o el cliente
Es fundamental identificar la causa raíz mediante una supervisión, un registro y un análisis exhaustivos, mientras que implementar mecanismos adecuados de administración de errores, agrupación de conexiones y reintentos puede ayudar a mitigar el impacto de estas desconexiones intermitentes en la funcionalidad de la aplicación y la experiencia del usuario.
## Recopilación de datos sobre problemas de conectividad para Aurora MySQL
La recopilación de datos completos relacionados con los componentes de la aplicación, la base de datos, la red y la infraestructura es crucial para solucionar eficazmente los problemas de conectividad entre una aplicación y una base de datos de Aurora MySQL. Al recopilar los registros, las configuraciones y la información de diagnóstico pertinentes, obtendrá información valiosa que puede ayudar a identificar la causa raíz de los problemas de conectividad y guiarlo hacia una solución adecuada.
Los registros y las configuraciones de la red, como las reglas de los grupos de seguridad, la configuración de la VPC y las tablas de enrutamiento, son esenciales para identificar posibles cuellos de botella o errores de configuración relacionados con la red que podrían impedir que la aplicación establezca una conexión correcta con la base de datos. Al analizar estos componentes de la red, puede asegurarse de que los puertos necesarios estén abiertos, que se permitan las direcciones IP y que las configuraciones de enrutamiento estén configuradas correctamente.
**Marcas temporales**
Registre las marcas horarias exactas en las que se producen los problemas de conectividad. Esto puede ayudar a identificar patrones o correlacionar los problemas con otros eventos o actividades.
**Registro del motor de base de datos**
Además de los registros generales de la base de datos, revise los registros del motor de base de datos (por ejemplo, el registro de errores de MySQL y el registro de consultas lentas) para ver si hay información relevante o errores que puedan estar relacionados con los problemas de conectividad intermitente. Para obtener más información, consulte [Registro de bases de datos Aurora MySQL](aurora-mysql-troubleshooting-logging.md).
**Registros de aplicaciones cliente**
Recopile registros detallados de las aplicaciones cliente que se conectan a la base de datos. Los registros de las aplicaciones permiten ver los intentos de conexión, los errores y cualquier información pertinente desde la perspectiva de la aplicación, lo que puede revelar problemas relacionados con las cadenas de conexión, las credenciales de autenticación o la administración de las conexiones de la aplicación.
Los registros de las bases de datos, por otro lado, ofrecen información sobre los errores de la base de datos, las consultas lentas o los eventos que podrían estar contribuyendo a los problemas de conectividad. Para obtener más información, consulte [Registro de bases de datos Aurora MySQL](aurora-mysql-troubleshooting-logging.md).
**Variables de entorno del cliente**
Compruebe si alguna variable de entorno o configuración del cliente podría estar afectando a la conexión de la base de datos, como la configuración del proxy, la configuración de SSL/TLS o cualquier otra variable pertinente.
**Versiones de la biblioteca del cliente**
Asegúrese de que el cliente utilice las versiones más recientes de los controladores, bibliotecas o marcos de bases de datos utilizados para la conectividad de las bases de datos. Las versiones desactualizadas pueden tener problemas conocidos o de compatibilidad.
**Captura de la red de clientes**
Realice una captura de red en el cliente mediante una herramienta como Wireshark o `tcpdump` en los momentos en que se produzcan problemas de conectividad. Esto puede ayudar a identificar cualquier problema o anomalía relacionados con la red del cliente.
**Topología de la red del cliente**
Comprenda la topología de la red del cliente, incluidos los firewalls, los equilibradores de carga u otros componentes, como el proxy RDS o el proxy SQL, que se conectan a la base de datos en lugar de que el cliente realice las conexiones directamente.
**Configuración del sistema operativo del cliente**
Compruebe la configuración del sistema operativo del cliente que pueda afectar a la conectividad de la red, como las reglas del firewall, la configuración del adaptador de red y cualquier otra configuración pertinente.
**Configuración de grupo de conexiones**
Si utiliza un mecanismo de agrupación de conexiones en su aplicación, revise los ajustes de configuración y supervise las métricas del grupo (por ejemplo, las conexiones activas, las conexiones inactivas y los tiempos de espera de conexión) para asegurarse de que el grupo funcione correctamente. Revise también la configuración del grupo, como el tamaño máximo, el tamaño mínimo y la configuración de validación de la conexión, para asegurarse de que están configurados correctamente.
**Cadena de conexión**
La cadena de conexión suele incluir parámetros como el nombre de host o punto de conexión, el número de puerto, el nombre de la base de datos y las credenciales de autenticación. El análisis de la cadena de conexión puede ayudar a identificar posibles errores de configuración o ajustes incorrectos que puedan estar causando problemas de conectividad. Por ejemplo, un nombre de host o un número de puerto incorrectos pueden impedir que el cliente acceda a la instancia de la base de datos, mientras que las credenciales de autenticación no válidas pueden provocar errores de autenticación y el rechazo de la conexión. Además, la cadena de conexión puede revelar problemas relacionados con la agrupación de conexiones, los tiempos de espera u otros ajustes específicos de la conexión que podrían contribuir a los problemas de conectividad. Proporcionar la cadena de conexión completa utilizada por la aplicación cliente puede ayudar a identificar cualquier error de configuración en el cliente.
**Métricas de la base de datos**
Supervise las métricas de bases de datos, como el uso de la CPU, el uso de la memoria y de la E/S del disco, durante los momentos en que se producen problemas de conectividad. Estas pueden ayudar a identificar si la instancia de base de datos tiene problemas de rendimiento o de contención de recursos.
**Versión del motor de base de datos**
Tenga en cuenta la versión del motor de base de datos de Aurora MySQL. AWS publica periódicamente actualizaciones que abordan los problemas conocidos y las vulnerabilidades de seguridad e introducen mejoras de rendimiento. Por lo tanto, le recomendamos encarecidamente que actualice a las últimas versiones disponibles, ya que estas actualizaciones suelen incluir correcciones de errores y mejoras relacionadas específicamente con la conectividad, el rendimiento y la estabilidad. Proporcionar la información sobre la versión de la base de datos, junto con el resto de los detalles recopilados, puede ayudar a Soporte diagnosticar y resolver los problemas de conectividad de forma eficaz.
**Métricas de red**
Recopile métricas de la red, como la latencia, la pérdida de paquetes y el rendimiento, durante los momentos en que se producen problemas de conectividad. Herramientas como `ping`, `traceroute` y las herramientas de supervisión de red pueden ayudar a recopilar estos datos.
**Datos de origen y cliente**
Determine las direcciones IP de los servidores de aplicaciones, los equilibradores de carga o cualquier otro componente que inicie las conexiones de la base de datos. Puede ser una única dirección IP o un intervalo de direcciones IP (notación de CIDR). Si el origen es una instancia de Amazon EC2, también es útil revisar el tipo de instancia, la zona de disponibilidad, el ID de subred y los grupos de seguridad asociados a la instancia, así como los detalles de la interfaz de red, como la dirección IP privada y la dirección IP pública.
Al analizar minuciosamente los datos recopilados, puede identificar los errores de configuración, las limitaciones de recursos, las interrupciones de la red u otros problemas subyacentes que están causando los problemas de conectividad intermitentes o persistentes. Esta información le permite tomar medidas específicas, como ajustar las configuraciones, resolver problemas de red o abordar la administración de la conexión de aplicación.
## Supervisión de las conexiones de bases de datos para Aurora MySQL
Para supervisar y solucionar problemas de conectividad, puede utilizar las siguientes métricas y características.
**Métricas de CloudWatch**
+ `CPUUtilization`: un uso elevado de la CPU en la instancia de base de datos puede provocar una ejecución lenta de las consultas, lo que puede provocar tiempos de espera o rechazos de la conexión.
+ `DatabaseConnections`: supervise el número de conexiones activas a la instancia de base de datos. Un número elevado de conexiones cercano al máximo configurado puede indicar posibles problemas de conectividad o el agotamiento del grupo de conexiones.
+ `FreeableMemory`: tener poca memoria disponible puede provocar problemas de rendimiento y conectividad como consecuencia de la escasez de recursos.
+ `NetworkReceiveThroughput` y `NetworkTransmitThroughput`: los picos o caídas inusuales en el rendimiento de la red pueden indicar problemas de conectividad o cuellos de botella en la red.
**Métricas de Información de rendimiento**
Para solucionar problemas de conectividad en Aurora MySQL mediante Información de rendimiento, analice las métricas de la base de datos como las siguientes:
+ Aborted\$1clients
+ Aborted\$1connects
+ Connections
+ max\$1connections
+ Threads\$1connected
+ Threads\$1created
+ Threads\$1running
Estas métricas pueden ayudarlo a identificar los cuellos de botella en la conexión, detectar problemas de red o de autenticación, optimizar la agrupación de conexiones y garantizar una administración eficiente de los subprocesos. Para obtener más información, consulte [Contadores de Información de rendimiento para Aurora MySQL](USER_PerfInsights_Counters.md#USER_PerfInsights_Counters.Aurora_MySQL).
**Características de Información de rendimiento**
+ **Carga de la base de datos**: visualice la carga de la base de datos a lo largo del tiempo y correlaciónela con los problemas de conectividad o la degradación del rendimiento.
+ **Estadísticas de SQL**: analice las estadísticas de SQL para identificar consultas u operaciones de base de datos ineficientes que puedan contribuir a los problemas de conectividad.
+ **Consultas principales**: identifique y analice las consultas que consumen más recursos, lo que puede ayudar a identificar posibles cuellos de botella en el rendimiento o consultas de larga duración que pueden estar causando problemas de conectividad.
Al supervisar estas métricas y aprovechar Información de rendimiento, puede obtener visibilidad del rendimiento de la instancia de base de datos, el uso de recursos y los posibles cuellos de botella que podrían estar causando problemas de conectividad. Por ejemplo:
+ Si `DatabaseConnections` se acerca mucho al límite máximo, puede indicar que se ha agotado el conjunto de conexiones o se ha administrado la conexión de forma inadecuada, lo que puede provocar problemas de conectividad.
+ Un nivel alto de `CPUUtilization` o bajo de `FreeableMemory` puede indicar limitaciones de recursos, lo que puede provocar una ejecución lenta de las consultas y tiempos de espera o rechazos de la conexión.
+ El análisis de las **consultas principales** y **estadísticas de SQL** puede ayudar a identificar las consultas ineficientes o que consumen muchos recursos y que pueden estar contribuyendo a los problemas de conectividad.
Además, la supervisión de registros de CloudWatch y la configuración de alarmas pueden ayudarlo a identificar y responder de forma proactiva a los problemas de conectividad antes de que se agraven.
Es importante tener en cuenta que, si bien estas métricas y herramientas pueden proporcionar información valiosa, deben utilizarse junto con otros pasos de solución de problemas. Al revisar también las configuraciones de red, las reglas de los grupos de seguridad y el manejo de la conexión de la aplicación, puede diagnosticar y resolver exhaustivamente los problemas de conectividad con las instancias de base de datos de Aurora MySQL.
### Supervisión adicional para Aurora MySQL
**Métricas de CloudWatch**
+ `AbortedClients`: realiza un seguimiento el número de conexiones de cliente que no se han cerrado correctamente.
+ `AuroraSlowConnectionHandleCount`: realiza un seguimiento del número de operaciones de administración de conexiones lentas, lo que indica posibles problemas de conectividad o cuellos de botella en el rendimiento.
+ `AuroraSlowHandshakeCount`: mide el número de operaciones de protocolos de enlace lentos, lo que también puede ser un indicador de problemas de conectividad.
+ `ConnectionAttempts`: mide el número de intentos de conexión realizados a la instancia de base de datos de Aurora MySQL.
**Variables de estado globales**
`Aurora_external_connection_count`: muestra el número de conexiones de base de datos a la instancia de base de datos, excluidas las conexiones al servicio RDS utilizadas para las comprobaciones de estado de la base de datos.
Al supervisar estas métricas y variables de estado global, puede obtener visibilidad de los patrones de conexión, los errores y los posibles cuellos de botella que pueden estar causando problemas de conectividad con su instancia de Amazon Aurora MySQL.
Por ejemplo, un número elevado de problemas de `AbortedClients` o `AuroraSlowConnectionHandleCount` puede indicar problemas de conectividad.
Además, configurar las alarmas y notificaciones de CloudWatch puede ayudarlo a identificar y responder de forma proactiva a los problemas de conectividad antes de que se agraven y afecten al rendimiento de la aplicación.
## Códigos de error de conectividad para Aurora MySQL
A continuación, se muestran algunos errores de conectividad comunes de las bases de datos Aurora MySQL, junto con sus códigos de error y sus explicaciones.
**Código de error 1040: Too many connections**
Este error se produce cuando el cliente intenta establecer más conexiones que el máximo permitido por el servidor de la base de datos. Entre las causas posibles, se incluyen:
+ Configuración incorrecta de la agrupación de conexiones: si utiliza un mecanismo de agrupación de conexiones, asegúrese de que el tamaño máximo de la agrupación no sea demasiado alto y de que las conexiones se devuelvan correctamente a la agrupación.
+ Configuración de la instancia de base de datos: compruebe la configuración máxima de conexiones permitidas para la instancia de base de datos y ajústela si es necesario configurando el parámetro `max_connections`.
+ Alta concurrencia: si varios clientes o aplicaciones se conectan a la base de datos simultáneamente, es posible que se alcance el límite máximo de conexiones permitido.
**Código de error 1045: Access denied for user '...'@'...' (using password: YES/NO)**
Este error indica un error de autenticación al intentar conectarse a la base de datos. Entre las causas posibles, se incluyen:
+ Compatibilidad con el complemento de autenticación: compruebe si el complemento de autenticación utilizado por el cliente es compatible con el mecanismo de autenticación del servidor de la base de datos.
+ Nombre de usuario o contraseña incorrectos: compruebe que se estén utilizando el nombre de usuario y la contraseña correctos en la cadena de conexión o en el mecanismo de autenticación.
+ Permisos de usuario: asegúrese de que el usuario tenga los permisos necesarios para conectarse a la instancia de base de datos desde el host o la red especificados.
**Código de error 1049: Unknown database '...'**
Este error indica que el cliente está intentando conectarse a una base de datos que no existe en el servidor. Entre las causas posibles, se incluyen:
+ Base de datos no creada: asegúrese de que la base de datos especificada se haya creado en el servidor de bases de datos.
+ Nombre de base de datos incorrecto: compruebe si el nombre de la base de datos utilizado en la cadena de conexión o consulta es correcto.
+ Permisos de usuario: compruebe que el usuario tenga los permisos necesarios para acceder a la base de datos especificada.
**Código de error 1153: Got a packet bigger than 'max\$1allowed\$1packet' bytes**
Este error se produce cuando el cliente intenta enviar o recibir datos que superan el tamaño máximo de paquete permitido por el servidor de bases de datos. Entre las causas posibles, se incluyen:
+ Consultas o conjuntos de resultados de gran tamaño: si se ejecutan consultas que implican grandes cantidades de datos, es posible que se exceda el límite de tamaño del paquete.
+ Configuración de tamaño de paquete mal configurada: compruebe la configuración de `max_allowed_packet` en el servidor de la base de datos y ajústela si es necesario.
+ Problemas de configuración de la red: asegúrese de que la configuración de la red (por ejemplo, el tamaño de la MTU) permita los tamaños de paquete requeridos.
**Código de error 1226: User '...' has exceeded the 'max\$1user\$1connections' resource (current value: ...)**
Este error indica que el usuario ha superado el número máximo de conexiones simultáneas permitido por el servidor de base de datos. Entre las causas posibles, se incluyen:
+ Configuración incorrecta de la agrupación de conexiones: si utiliza un mecanismo de agrupación de conexiones, asegúrese de que el tamaño máximo de la agrupación no sea demasiado alto para el límite de conexiones del usuario.
+ Configuración de la instancia de base de datos: compruebe la configuración de `max_user_connections` para la instancia de base de datos y ajústela si es necesario.
+ Alta concurrencia: si varios clientes o aplicaciones se conectan a la base de datos simultáneamente con el mismo usuario, es posible que se alcance el límite máximo de conexiones específicas del usuario.
**Código de error 2003: Can't connect to MySQL server on '...' (10061)**
Este error suele producirse cuando el cliente no puede establecer una conexión TCP/IP con el servidor de la base de datos. Puede deberse a varios problemas, como los siguientes:
+ Estado de la instancia de base de datos: asegúrese de que la instancia de base de datos esté en el estado `available` y no esté siendo sometida a ninguna operación de mantenimiento ni copia de seguridad.
+ Reglas de firewall: compruebe si algún firewall (sistema operativo, red o grupo de seguridad) está bloqueando la conexión en el puerto especificado (normalmente el 3306 para MySQL).
+ Nombre de host o punto de conexión incorrectos: asegúrese de que el nombre de host o punto de conexión utilizado en la cadena de conexión sea correcto y coincida con la instancia de base de datos.
+ Problemas de conectividad de red: compruebe que el equipo cliente pueda acceder a la instancia de base de datos a través de la red. Compruebe si hay interrupciones en la red, problemas de enrutamiento o errores de configuración de la VPC o de la subred.
**Código de error 2005: Unknown MySQL server host '...' (11001)**
Este error se produce cuando el cliente no puede resolver el nombre de host o el punto de conexión del servidor de la base de datos en una dirección IP. Entre las causas posibles, se incluyen:
+ Problemas de resolución de DNS: compruebe que el equipo cliente pueda resolver el nombre de host correctamente mediante DNS. Compruebe la configuración de DNS y la caché de DNS e intente utilizar la dirección IP en lugar del nombre de host.
+ Nombre de host o punto de conexión incorrectos: compruebe si el nombre de host o el punto de conexión utilizados en la cadena de conexión son correctos.
+ Problemas de configuración de red: asegúrese de que la configuración de red del cliente (por ejemplo, VPC, subred y tablas de enrutamiento) permita la resolución de DNS y la conectividad a la instancia de la base de datos.
**Código de error 2026: SSL connection error**
Este error se produce cuando hay un problema con la configuración de SSL/TLS o la validación del certificado durante el intento de conexión. Entre las causas posibles, se incluyen:
+ Caducidad del certificado: compruebe si el certificado SSL/TLS utilizado por el servidor ha caducado y debe renovarse.
+ Problemas con la validación del certificado: compruebe que el cliente puede validar correctamente el certificado SSL/TLS del servidor y que el certificado es de confianza.
+ Problemas de configuración de red: asegúrese de que la configuración de red permita las conexiones SSL/TLS y no bloquee ni interfiera con el proceso de protocolo de enlace SSL/TLS.
+ La configuración de SSL/TLS no coincide: asegúrese de que la configuración de SSL/TLS (por ejemplo, los conjuntos de cifrado y las versiones de los protocolos) del cliente y el servidor sea compatible.
Si comprende las explicaciones detalladas y las posibles causas de cada código de error, podrá solucionar mejor los problemas de conectividad al trabajar con bases de datos Aurora MySQL.
## Recomendaciones de ajuste de parámetros para Aurora MySQL
**Número máximo de conexiones**
El ajuste de estos parámetros puede ayudar a evitar problemas de conexión causados por alcanzar el límite máximo de conexiones permitido. Asegúrese de que estos valores estén configurados adecuadamente en función de los requisitos de concurrencia y las limitaciones de recursos de la aplicación.
+ `max_connections`: este parámetro especifica el número máximo de conexiones simultáneas que se permite a la instancia de base de datos.
+ `max_user_connections`: este parámetro se puede especificar durante la creación y modificación del usuario, y establece el número máximo de conexiones simultáneas permitidas para una cuenta de usuario específica.
**Tamaño del búfer de red**
El aumento de estos valores puede mejorar el rendimiento de la red, especialmente en el caso de cargas de trabajo que implican grandes transferencias de datos o conjuntos de resultados. Sin embargo, tenga cuidado, ya que los tamaños de búfer más grandes pueden consumir más memoria.
+ `net_buffer_length`: este parámetro establece el tamaño inicial de los búferes de conexión al cliente y de resultados, equilibrando el uso de memoria con el rendimiento de las consultas.
+ `max_allowed_packet`: este parámetro especifica el tamaño máximo de un único paquete de red que la instancia de base de datos puede enviar o recibir.
**Compresión de red (en el cliente)**
Habilitar la compresión de la red puede reducir el uso del ancho de banda de la red, pero puede aumentar la sobrecarga de la CPU tanto en el cliente como en el servidor.
+ `compress`: este parámetro habilita o deshabilita la compresión de red para la comunicación entre el cliente y el servidor.
+ `compress_protocol`: este parámetro especifica el protocolo de compresión que se utilizará para la comunicación de red.
**Ajuste del rendimiento de la red**
Ajustar estos tiempos de espera puede ayudar a administrar las conexiones inactivas y evitar el agotamiento de los recursos, pero tenga cuidado, ya que los valores bajos pueden provocar la finalización prematura de las conexiones.
+ `interactive_timeout`: este parámetro especifica el número de segundos que el servidor espera a que se produzca actividad en una conexión interactiva antes de cerrarla.
+ `wait_timeout`: este parámetro determina el número de segundos que el servidor espera a que se produzca actividad en una conexión no interactiva antes de cerrarla.
**Configuración de tiempo de espera de la red**
Ajustar estos tiempos de espera puede ayudar a solucionar los problemas relacionados con las conexiones lentas o que no responden. Sin embargo, tenga cuidado de no usar valores demasiado bajos, ya que puede provocar fallos de conexión prematuros.
+ `net_read_timeout`: este parámetro especifica el número de segundos que se deben esperar para recibir más datos de una conexión antes de finalizar la operación de lectura.
+ `net_write_timeout`: este parámetro determina el número de segundos que se debe esperar a que se escriba un bloque en una conexión antes de finalizar la operación de escritura.
## Ejemplos de solución de problemas de conexión de bases de datos para Aurora MySQL
Los siguientes ejemplos muestran cómo identificar y solucionar los problemas de conexión a bases de datos de Aurora MySQL.
### Ejemplo 1: Solución de problemas de intentos de conexión fallidos
Los intentos de conexión pueden fallar por varios motivos, incluidos los errores de autenticación, los errores del protocolo de enlace SSL/TLS, el límite `max_connections` alcanzado y las restricciones de recursos de la instancia de base de datos.
Puede realizar un seguimiento del número de conexiones fallidas desde Información de rendimiento, o mediante el siguiente comando.
```
mysql> show global status like 'aborted_connects';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| Aborted_connects | 7 |
+------------------+-------+
1 row in set (0.00 sec)
```
Si el número de `Aborted_connects` aumenta con el tiempo, es posible que la aplicación tenga problemas de conectividad intermitentes.
Puede usar [Aurora Advanced Auditing](AuroraMySQL.Auditing.md) para registrar las conexiones y desconexiones de las conexiones del cliente. Para ello, defina los siguientes parámetros en el grupo de parámetros de clúster de base de datos:
+ `server_audit_logging` = `1`
+ `server_audit_events` = `CONNECT`
El siguiente es un extracto de los registros de auditoría de un inicio de sesión fallido.
```
1728498527380921,auora-mysql-node1,user_1,172.31.49.222,147189,0,FAILED_CONNECT,,,1045
1728498527380940,auora-mysql-node1,user_1,172.31.49.222,147189,0,DISCONNECT,,,0
```
Donde:
+ `1728498527380921`: la marca temporal de la época en la que se produjo el error de inicio de sesión
+ `aurora-mysql-node1`: el identificador de instancia del nodo del clúster de Aurora MySQL en el que se produjo un error de conexión
+ `user_1`: el nombre del usuario de base de datos para el que no se pudo iniciar sesión
+ `172.31.49.222`: la dirección IP privada del cliente desde el que se estableció la conexión
+ `147189`: el ID de conexión del inicio de sesión fallido
+ `FAILED_CONNECT`: indica que la conexión ha fallado
+ `1045`: el código de devolución Un valor distinto de cero indica un error. En este caso, `1045` corresponde al acceso denegado.
Para obtener más información, consulte [Server error codes](https://dev.mysql.com/doc/mysql-errors/5.7/en/server-error-reference.html) y [Client error codes](https://dev.mysql.com/doc/mysql-errors/5.7/en/client-error-reference.html) en la documentación de MySQL.
También puede examinar los registros de errores de Aurora MySQL para ver si hay algún mensaje de error relacionado, por ejemplo:
```
2024-10-09T19:26:59.310443Z 220 [Note] [MY-010926] [Server] Access denied for user 'user_1'@'172.31.49.222' (using password: YES) (sql_authentication.cc:1502)
```
### Ejemplo 2: Solución de problemas de desconexiones anómalas de un cliente
Puede realizar un seguimiento del número de desconexiones anómalas de un cliente desde Información de rendimiento o mediante el siguiente comando.
```
mysql> show global status like 'aborted_clients';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| Aborted_clients | 9 |
+-----------------+-------+
1 row in set (0.01 sec)
```
Si el número de `Aborted_clients` aumenta con el tiempo, significa que la aplicación no cierra correctamente las conexiones a la base de datos. Si las conexiones no se cierran correctamente, se pueden producir pérdidas de recursos y posibles problemas de rendimiento. Dejar las conexiones abiertas innecesariamente puede consumir recursos del sistema, como la memoria y los descriptores de archivos, lo que puede provocar que la aplicación o el servidor dejen de responder o se reinicien.
Puede utilizar la siguiente consulta para identificar las cuentas que no cierran conexiones correctamente. Recupera el nombre de la cuenta de usuario, el host desde el que se conecta el usuario, el número de conexiones no cerradas y el porcentaje de conexiones no cerradas.
```
SELECT
ess.user,
ess.host,
(a.total_connections - a.current_connections) - ess.count_star AS not_closed,
(((a.total_connections - a.current_connections) - ess.count_star) * 100) / (a.total_connections - a.current_connections) AS pct_not_closed
FROM
performance_schema.events_statements_summary_by_account_by_event_name AS ess
JOIN performance_schema.accounts AS a ON (ess.user = a.user AND ess.host = a.host)
WHERE
ess.event_name = 'statement/com/quit'
AND (a.total_connections - a.current_connections) > ess.count_star;
+----------+---------------+------------+----------------+
| user | host | not_closed | pct_not_closed |
+----------+---------------+------------+----------------+
| user1 | 172.31.49.222 | 1 | 33.3333 |
| user1 | 172.31.93.250 | 1024 | 12.1021 |
| user2 | 172.31.93.250 | 10 | 12.8551 |
+----------+---------------+------------+----------------+
3 rows in set (0.00 sec)
```
Tras identificar las cuentas de usuario y los hosts desde los que no se cierran las conexiones, puede comprobar el código que no cierra correctamente las conexiones.
Por ejemplo, con el conector MySQL en Python, utilice el método `close()` del objeto de conexión para cerrar las conexiones. A continuación, se muestra un ejemplo de función que establece una conexión a una base de datos, realiza una consulta y cierra la conexión:
```
import mysql.connector
def execute_query(query):
# Establish a connection to the database
connection = mysql.connector.connect(
host="your_host",
user="your_username",
password="your_password",
database="your_database"
)
try:
# Create a cursor object
cursor = connection.cursor()
# Execute the query
cursor.execute(query)
# Fetch and process the results
results = cursor.fetchall()
for row in results:
print(row)
finally:
# Close the cursor and connection
cursor.close()
connection.close()
```
En este ejemplo, se llama al método `connection.close()` en el bloque `finally` para asegurarse de que la conexión está cerrada, se produzca o no una excepción.
### Ejemplo 3: Solución de problemas de intentos de conexión erróneos de IAM
La conectividad con usuarios de AWS Identity and Access Management (IAM) puede errores por varios motivos, como:
+ Configuración de política de IAM incorrecta
+ Credenciales de seguridad caducadas
+ Problemas de conectividad de red
+ No coinciden los permisos de la base de datos
Para solucionar estos errores de autenticación, active la característica de exportación de registros de `iam-db-auth-error` en el servicio de la base de datos relacional (RDS) de Amazon o base de datos de Aurora. Esto le permitirá ver los mensajes de error de autenticación detallados en el grupo de registros de CloudWatch para el clúster de Amazon RDS o Amazon Aurora.
Una vez habilitados, puede revisar estos registros para identificar y resolver la causa específica de los errores de autenticación de IAM.
Por ejemplo:
```
2025-09-22T12:02:30,806 [ERROR] Failed to authorize the connection request for user 'user_1' due to an internal IAM DB Auth error. (Status Code: 500, Error Code: InternalError)
```
y
```
2025-09-22T12:02:51,954 [ERROR] Failed to authenticate the connection request for user 'user_2' because the provided token is malformed or otherwise invalid. (Status Code: 400, Error Code: InvalidToken)
```
Para obtener orientación sobre la solución de problemas, consulte la guía de solución de problemas de [Aurora](UsingWithRDS.IAMDBAuth.Troubleshooting.md) para la autenticación de bases de datos de IAM.
# Solución de problemas de rendimiento de consultas de las bases de datos Aurora MySQL
MySQL proporciona [control del optimizador de consultas](https://dev.mysql.com/doc/refman/8.0/en/controlling-optimizer.html) a través de variables del sistema que afectan a la forma en que se evalúan los planes de consultas, las optimizaciones intercambiables, las sugerencias de optimizadores e índices y el modelo de costos del optimizador. Estos puntos de datos pueden ser útiles no solo al comparar diferentes entornos MySQL, sino también para comparar los planes de ejecución de consultas anteriores con los planes de ejecución actuales y para comprender la ejecución general de una consulta MySQL en cualquier momento.
El rendimiento de las consultas depende de muchos factores, como el plan de ejecución, el esquema y tamaño de las tablas, las estadísticas, los recursos, los índices y la configuración de los parámetros. El ajuste de las consultas requiere identificar cuellos de botella y optimizar la ruta de ejecución.
+ Busque el plan de ejecución de la consulta y compruebe si la consulta utiliza los índices adecuados. Para optimizar la consulta, puede utilizar `EXPLAIN` y revisar los detalles de cada plan.
+ Aurora MySQL versión 3 (compatible con MySQL 8.0 Community Edition) utiliza una instrucción `EXPLAIN ANALYZE`. La instrucción `EXPLAIN ANALYZE` es una herramienta de elaboración de perfiles que indica en dónde MySQL dedica tiempo a su consulta y por qué. Con `EXPLAIN ANALYZE`, Aurora MySQL planifica, prepara y ejecuta la consulta mientras cuenta las filas y mide el tiempo empleado en varios puntos del plan de ejecución. Cuando se completa la consulta, `EXPLAIN ANALYZE` imprime el plan y sus medidas en lugar del resultado de la consulta.
+ Mantenga las estadísticas del esquema actualizadas mediante la instrucción `ANALYZE`. A veces, el optimizador de consultas puede elegir planes de ejecución inadecuados debido a que las estadísticas están desactualizadas. Esto puede provocar un rendimiento deficiente de una consulta debido a que las estimaciones de cardinalidad de las tablas y los índices no son exactas. La columna `last_update` de la tabla [innodb\$1table\$1stats](https://dev.mysql.com/doc/refman/8.0/en/innodb-persistent-stats.html#innodb-persistent-stats-tables) muestra la última vez que se actualizaron las estadísticas del esquema, lo que es un buen indicador de que están “estancadas”.
+ Pueden producirse otros problemas, como un sesgo en la distribución de los datos, que no se tienen en cuenta para determinar la cardinalidad de la tabla. Para obtener más información, consulte [Estimating ANALYZE TABLE complexity for InnoDB tables](https://dev.mysql.com/doc/refman/8.0/en/innodb-analyze-table-complexity.html) y [Histogram statistics in MySQL](https://dev.mysql.com/blog-archive/histogram-statistics-in-mysql/) en la documentación de MySQL.
## Descripción del tiempo que emplean las consultas
Estas son formas de determinar el tiempo que emplean las consultas:
+ [Elaboración de perfiles](https://dev.mysql.com/doc/refman/8.0/en/show-profile.html)
+ [Performance Schema](https://dev.mysql.com/doc/refman/8.0/en/performance-schema.html)
+ [Optimizador de consultas](https://dev.mysql.com/doc/refman/8.0/en/controlling-optimizer.html)
**Creación de perfiles**
La elaboración de perfiles está deshabilitada de forma predeterminada. Habilite la elaboración de perfiles y, a continuación, ejecute la consulta lenta y revise su perfil.
```
SET profiling = 1;
Run your query.
SHOW PROFILE;
```
1. Identifique la etapa en la que pasa más tiempo. De acuerdo con [General thread states](https://dev.mysql.com/doc/refman/8.0/en/general-thread-states.html), en la documentación de MySQL, leer y procesar filas de una instrucción `SELECT` determinada suele ser el estado que tarda más tiempo en ejecutarse a lo largo de la vida útil de una consulta. Puede usar la instrucción `EXPLAIN` para saber cómo MySQL ejecuta esta consulta.
1. Revise el registro de consultas lentas para evaluar `rows_examined` y `rows_sent` para asegurarse de que la carga de trabajo es similar en cada entorno. Para obtener más información, consulte [Registro de bases de datos Aurora MySQL](aurora-mysql-troubleshooting-logging.md).
1. Ejecute el siguiente comando para las tablas que forman parte de la consulta identificada:
```
SHOW TABLE STATUS\G;
```
1. Obtenga la siguiente salida antes y después de ejecutar la consulta en cada entorno:
```
SHOW GLOBAL STATUS;
```
1. Ejecute los siguientes comandos en cada entorno para comprobar si hay alguna otra consulta o sesión que influya en el rendimiento de esta consulta de ejemplo.
```
SHOW FULL PROCESSLIST;
SHOW ENGINE INNODB STATUS\G;
```
A veces, cuando los recursos del servidor están ocupados, esto afecta a todas las demás operaciones del servidor, incluidas las consultas. También puede obtener información periódicamente cuando se ejecutan consultas o configurar un trabajo de `cron` para obtener información a intervalos útiles.
**Performance Schema**
Performance Schema proporciona información útil sobre el rendimiento del tiempo de ejecución del servidor y, al mismo tiempo, tiene un impacto mínimo en ese rendimiento. Es diferente de `information_schema`, que proporciona información de esquema sobre la instancia de base de datos. Para obtener más información, consulte [Descripción general de Performance Schema para Información de rendimiento en Aurora MySQL](USER_PerfInsights.EnableMySQL.md).
**Seguimiento del optimizador de consultas**
Para entender por qué [se eligió un plan de consultas en particular para su ejecución](https://dev.mysql.com/doc/refman/8.0/en/execution-plan-information.html), puede configurar `optimizer_trace` para acceder al optimizador de consultas de MySQL.
Ejecute un seguimiento del optimizador para ver información exhaustiva sobre todas las rutas disponibles para el optimizador y su elección.
```
SET SESSION OPTIMIZER_TRACE="enabled=on";
SET optimizer_trace_offset=-5, optimizer_trace_limit=5;
-- Run your query.
SELECT * FROM table WHERE x = 1 AND y = 'A';
-- After the query completes:
SELECT * FROM information_schema.OPTIMIZER_TRACE;
SET SESSION OPTIMIZER_TRACE="enabled=off";
```
## Revisión de la configuración del optimizador de consultas
Aurora MySQL versión 3 (compatible con MySQL 8.0 Community Edition) tiene muchos cambios relacionados con el optimizador en comparación con Aurora MySQL versión 2 (compatible con MySQL 5.7 Community Edition). Si tiene algunos valores personalizados para `optimizer_switch`, le recomendamos que revise las diferencias entre los valores predeterminados y establezca los valores de `optimizer_switch` que mejor se adapten a su carga de trabajo. También le recomendamos que pruebe las opciones disponibles para la versión 3 de Aurora MySQL para examinar el rendimiento de las consultas.
**nota**
La versión 3 de Aurora MySQL utiliza el valor predeterminado de 20 de la comunidad para el parámetro [innodb\$1stats\$1persistent\$1sample\$1pages](https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_stats_persistent_sample_pages).
Puede utilizar el siguiente comando para mostrar los valores de `optimizer_switch`:
```
SELECT @@optimizer_switch\G;
```
En la tabla siguiente, se muestran los valores predeterminados de `optimizer_switch` en Aurora MySQL versiones 2 y 3.
| Opción | Aurora MySQL versión 2 | Aurora MySQL versión 3 |
| --- | --- | --- |
| batched\$1key\$1access | apagar | apagar |
| block\$1nested\$1loop | on | on |
| condition\$1fanout\$1filter | on | on |
| derived\$1condition\$1pushdown | – | on |
| derived\$1merge | on | on |
| duplicateweedout | on | on |
| engine\$1condition\$1pushdown | on | on |
| firstmatch | on | on |
| hash\$1join | apagar | on |
| hash\$1join\$1cost\$1based | on | – |
| hypergraph\$1optimizer | – | apagar |
| index\$1condition\$1pushdown | on | on |
| index\$1merge | on | on |
| index\$1merge\$1intersection | on | on |
| index\$1merge\$1sort\$1union | on | on |
| index\$1merge\$1union | on | on |
| loosescan | on | on |
| materialization | on | on |
| mrr | on | on |
| mrr\$1cost\$1based | on | on |
| prefer\$1ordering\$1index | on | on |
| semijoin | on | on |
| skip\$1scan | – | on |
| subquery\$1materialization\$1cost\$1based | on | on |
| subquery\$1to\$1derived | – | apagar |
| use\$1index\$1extensions | on | on |
| use\$1invisible\$1indexes | – | apagar |
Para obtener más información, consulte [Switchable optimizations (MySQL 5.7)](https://dev.mysql.com/doc/refman/5.7/en/switchable-optimizations.html) y [Switchable optimizations (MySQL 8.0)](https://dev.mysql.com/doc/refman/8.0/en/switchable-optimizations.html) en la documentación de MySQL.