# synch/mutex/innodb/temp\$1pool\$1manager\$1mutex
El evento de espera `synch/mutex/innodb/temp_pool_manager_mutex` se produce cuando una sesión está esperando para adquirir un mutex para administrar el grupo de espacios de tablas temporales de sesión.
**Topics**
+ [Versiones del motor admitidas](#ams-waits.io-temppoolmanager.context.supported)
+ [Contexto](#ams-waits.io-temppoolmanager.context)
+ [Causas probables del aumento de las esperas](#ams-waits.io-temppoolmanager.causes)
+ [Acciones](#ams-waits.io-temppoolmanager.actions)
## Versiones del motor admitidas
Esta información de evento de espera es compatible con las siguientes versiones del motor:
+ Aurora MySQL versión 3
## Contexto
La versión 3.x y posterior de Aurora MySQL utiliza `temp_pool_manager_mutex` para controlar varias sesiones que acceden al grupo de espacios de tablas temporales al mismo tiempo. Aurora MySQL administra el almacenamiento a través de un volumen de clúster de Aurora para los datos persistentes y el almacenamiento local para los archivos temporales. Se necesita un espacio de tabla temporal cuando una sesión crea una tabla temporal en el volumen del clúster DE Aurora.
Cuando una sesión solicita por primera vez un espacio de tabla temporal, MySQL asigna los espacios de tablas temporales de sesión del grupo compartido. Una sesión puede contener hasta 2 espacios de tablas temporales a la vez para los siguientes tipos de tablas:
+ Tablas temporales creadas por el usuario
+ Tablas temporales internas generadas por el optimizador
El motor de `TempTable` predeterminado utiliza el siguiente mecanismo de desbordamiento para gestionar las tablas temporales:
+ Almacena las tablas en RAM hasta el límite [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram).
+ Se traslada a los archivos asignados a memoria del almacenamiento local cuando la RAM está llena.
+ Usa el volumen del clúster compartido cuando los archivos asignados a memoria alcanzan su límite [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap).
Cuando las tablas temporales superan los límites de RAM y almacenamiento local, MySQL las administra mediante el espacio de tablas del disco.
Cuando una sesión requiere una tabla temporal en disco, MySQL:
+ Busca los espacios de tablas `INACTIVE` disponibles en el grupo para reutilizarlos.
+ Crea 10 espacios de tabla nuevos si no hay espacios `INACTIVE`.
Cuando una sesión se desconecta, MySQL:
+ Trunca los espacios de tablas temporales de la sesión.
+ Los marca como INACTIVOS en el grupo para su reutilización.
+ Mantiene el tamaño actual del grupo hasta que se reinicie el servidor.
+ Vuelve al tamaño de grupo predeterminado (10 espacios de tabla) tras el reinicio.
## Causas probables del aumento de las esperas
Situaciones comunes que provocan este evento de espera:
+ Sesiones simultáneas que crean tablas temporales internas en el volumen del clúster.
+ Sesiones simultáneas que crean tablas temporales de usuario en el volumen del clúster.
+ Terminación repentina de las sesiones mediante espacios de tabla activos.
+ Expansión del grupo de espacios de tabla durante cargas de trabajo de escritura intensivas.
+ Consultas simultáneas mediante el acceso a `INFORMATION_SCHEMA.`
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
**Topics**
+ [Supervisión y optimización del uso de las tablas temporales](#ams-waits.io-temppoolmanager.actions.monitor)
+ [Revisión de las consultas mediante INFORMATION\$1SCHEMA](#ams-waits.io-temppoolmanager.actions.schema-queries)
+ [Aumento del parámetro innodb\$1sync\$1array\$1size](#ams-waits.io-temppoolmanager.actions.sync_array)
+ [Implementar la agrupación de conexiones](#ams-waits.io-temppoolmanager.actions.connection_pooling)
### Supervisión y optimización del uso de las tablas temporales
Para supervisar y optimizar el uso temporal de las tablas, utilice uno de estos métodos:
+ Consulte el contador de `Created_tmp_disk_tables` en la información de rendimiento para realizar un seguimiento de la creación de tablas temporales en disco en todo el clúster de Aurora.
+ Ejecute este comando en la base de datos para supervisar directamente la creación de tablas temporales: `mysql> show status like '%created_tmp_disk%'`.
**nota**
El comportamiento de las tablas temporales difiere entre los nodos de lectura y escritura de Aurora MySQL. Para obtener más información, consulte [Nuevo comportamiento de tabla temporal en Aurora MySQL versión 3](ams3-temptable-behavior.md).
Tras identificar las consultas mediante la creación de tablas temporales, siga estos pasos de optimización:
+ Use `EXPLAIN` para examinar los planes de ejecución de consultas e identificar dónde y por qué se crean las tablas temporales.
+ Modifique las consultas para reducir el uso temporal de las tablas siempre que sea posible.
Si la optimización de consultas por sí sola no resuelve los problemas de rendimiento, considere la posibilidad de ajustar estos parámetros de configuración:
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram): controla el uso máximo de RAM para las tablas temporales.
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap): establece el límite de almacenamiento de archivos asignados en memoria.
+ [https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size): se aplica cuando `aurora_tmptable_enable_per_table_limit` está habilitado (desactivado de forma predeterminada).
**importante**
Tenga en cuenta que determinadas condiciones de consulta siempre requerirán tablas temporales en disco, independientemente de los ajustes de configuración. Para obtener más información sobre el motor de almacenamiento de `TempTable`, consulte [Use the TempTable storage engine on Amazon RDS for MySQL and Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).
### Revisión de las consultas mediante INFORMATION\$1SCHEMA
Al consultar tablas de `INFORMATION_SCHEMA`, MySQL crea tablas temporales de InnoDB en el volumen del clúster. Cada sesión necesita un espacio de tablas temporal para estas tablas, lo que puede provocar problemas de rendimiento si el acceso simultáneo es elevado.
Para mejorar el desempeño:
+ Use `PERFORMANCE_SCHEMA` en lugar de `INFORMATION_SCHEMA` cuando sea posible.
+ Si debe utilizar `INFORMATION_SCHEMA`, reduzca la frecuencia con la que ejecuta estas consultas.
### Aumento del parámetro innodb\$1sync\$1array\$1size
El parámetro `innodb_sync_array_size` controla el tamaño de la matriz de espera mutex/lock en MySQL. El valor predeterminado de `1` funciona para cargas de trabajo generales, pero aumentarlo puede reducir la contención de subprocesos en situaciones de alta concurrencia.
Cuando la carga de trabajo muestra un número creciente de subprocesos en espera:
+ Supervise la cantidad de subprocesos de espera de la carga de trabajo.
+ Establezca un `innodb_sync_array_size` igual o superior al de la vCPU de la instancia para dividir la estructura de coordinación de subprocesos y reducir la contención.
**nota**
Para determinar la cantidad de vCPU disponibles en la instancia de RDS, consulte las especificaciones de las vCPU en los [tipos de instancias de Amazon RDS](https://aws.amazon.com/rds/instance-types/).
### Implementar la agrupación de conexiones
MySQL asigna un espacio de tabla dedicado a cada sesión que crea una tabla temporal. Este espacio de tabla permanece activo hasta que finalice la conexión a la base de datos. Para administrar los recursos de manera más eficiente:
+ Implemente la agrupación de conexiones para limitar el número de espacios de tabla temporales activos.
+ Reutilice las conexiones existentes en lugar de crear nuevas para cada operación.