# synch/mutex/innodb/temp\$1pool\$1manager\$1mutex O evento de espera `synch/mutex/innodb/temp_pool_manager_mutex` ocorre quando uma sessão está aguardando para adquirir um mutex para gerenciar o grupo de espaços para tabela temporários de sessão. **Topics** + [Versões compatíveis do mecanismo](#ams-waits.io-temppoolmanager.context.supported) + [Contexto](#ams-waits.io-temppoolmanager.context) + [Possíveis causas do maior número de esperas](#ams-waits.io-temppoolmanager.causes) + [Ações](#ams-waits.io-temppoolmanager.actions) ## Versões compatíveis do mecanismo Essas informações de eventos de espera têm suporte nas seguintes versões do mecanismo: + Aurora MySQL versão 3 ## Contexto O Aurora MySQL versão 3.x e posterior usa `temp_pool_manager_mutex` para controlar várias sessões acessando o grupo temporário de espaços para tabela ao mesmo tempo. O Aurora MySQL gerencia o armazenamento por meio de um volume de cluster do Aurora para dados persistentes e armazenamento local para arquivos temporários. Um espaço para tabela temporário é necessário quando uma sessão cria uma tabela temporária no volume de cluster do Aurora. Quando uma sessão solicita pela primeira vez um espaço para tabela temporário, o MySQL aloca espaços para tabela temporários da sessão do grupo compartilhado. Uma sessão pode conter até dois espaços para tabela temporários por vez para os seguintes tipos de tabela: + Tabelas temporárias criadas pelo usuário. + Tabelas temporárias internas geradas pelo otimizador O mecanismo `TempTable` padrão usa o seguinte mecanismo de transbordamento para lidar com tabelas temporárias: + Armazena tabelas na RAM até o limite [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). + Muda para arquivos mapeados na memória no armazenamento local quando a RAM está cheia. + Usa o volume do cluster compartilhado quando os arquivos mapeados na memória atingem o limite [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). Depois que as tabelas temporárias excedem os limites da RAM e do armazenamento local, o MySQL as gerencia usando o espaço para tabela em disco. Quando uma sessão exige uma tabela temporária em disco, o MySQL: + Procura espaços para tabela `INACTIVE` disponíveis no grupo para reutilização. + Criará dez espaços para tabela se não existirem espaços `INACTIVE`. Quando uma sessão é desconectada, o MySQL: + Trunca os espaços para tabela temporários da sessão. + Marca-os como INACTIVE no grupo para reutilização. + Mantém o tamanho atual do grupo até a reinicialização do servidor. + Volta ao tamanho padrão do grupo (dez espaços para tabela) após a reinicialização. ## Possíveis causas do maior número de esperas Situações comuns que causam esse evento de espera: + Sessões simultâneas que criam tabelas temporárias internas no volume do cluster. + Sessões simultâneas que criam tabelas temporárias no volume do cluster. + Encerramento repentino de sessões que usam espaços para tabela ativos. + Expansão do grupo de espaços para tabela durante workloads com uso intenso de gravação. + Consultas simultâneas que acessam `INFORMATION_SCHEMA.` ## Ações Recomenda-se ações distintas, dependendo dos motivos do evento de espera. **Topics** + [Monitorar e otimizar o uso de tabelas temporárias](#ams-waits.io-temppoolmanager.actions.monitor) + [Analisar as consultas usando INFORMATION\$1SCHEMA](#ams-waits.io-temppoolmanager.actions.schema-queries) + [Aumentar o parâmetro innodb\$1sync\$1array\$1size](#ams-waits.io-temppoolmanager.actions.sync_array) + [Implementar um pool de conexões](#ams-waits.io-temppoolmanager.actions.connection_pooling) ### Monitorar e otimizar o uso de tabelas temporárias Para monitorar e otimizar o uso de tabelas temporárias, use um destes métodos: + Confira o contador `Created_tmp_disk_tables` no Insights de Performance para monitorar a criação de tabelas temporárias em disco no cluster do Aurora. + Execute este comando em seu banco de dados para monitorar diretamente a criação de tabelas temporárias: `mysql> show status like '%created_tmp_disk%'`. **nota** O comportamento da tabela temporária difere entre os nós de leitura e gravação do Aurora MySQL. Para obter mais informações, consulte [Novo comportamento de tabela temporária no Aurora MySQL versão 3](ams3-temptable-behavior.md). Depois de identificar as consultas que criam tabelas temporárias, siga estas etapas de otimização: + Use `EXPLAIN` para examinar os planos de execução de consultas e identificar onde e por que as tabelas temporárias estão sendo criadas. + Modifique as consultas para reduzir o uso de tabelas temporárias sempre que possível. Se a otimização de consultas por si só não resolver os problemas de performance, pense em ajustar estes parâmetros de configuração: + [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 o uso máximo de RAM para tabelas temporárias. + [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): define o limite para armazenamento de arquivos mapeados na memória. + [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): aplica-se quando `aurora_tmptable_enable_per_table_limit` está habilitado (desabilitado por padrão). **Importante** Observe que determinadas condições de consulta sempre exigirão tabelas temporárias em disco, independentemente das configurações. Para acessar mais informações sobre o mecanismo de armazenamento `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/). ### Analisar as consultas usando INFORMATION\$1SCHEMA Quando você consulta tabelas `INFORMATION_SCHEMA`, o MySQL cria tabelas temporárias do InnoDB no volume do cluster. Cada sessão precisa de um espaço para tabela temporário para essas tabelas, o que pode causar problemas de performance durante o alto acesso simultâneo. Para melhorar a performance: + Use `PERFORMANCE_SCHEMA` em vez de `INFORMATION_SCHEMA` sempre que possível. + Se você precisar usar `INFORMATION_SCHEMA`, reduza a frequência com que você executa essas consultas. ### Aumentar o parâmetro innodb\$1sync\$1array\$1size O parâmetro `innodb_sync_array_size` controla o tamanho da matriz de espera mutex/lock no MySQL. O valor padrão de `1` funciona para workloads gerais, mas aumentá-lo pode reduzir a contenção de threads durante a alta simultaneidade. Quando sua workload mostra um número crescente de threads de espera: + Monitore o número de threads de espera em sua workload. + Defina `innodb_sync_array_size` igual ou superior à contagem de vCPUs da sua instância para dividir a estrutura de coordenação de threads e reduzir a contenção. **nota** Para determinar o número de vCPUs disponíveis em sua instância do RDS, consulte as especificações da vCPU em [Tipos de instância do Amazon RDS](https://aws.amazon.com/rds/instance-types/). ### Implementar um pool de conexões O MySQL atribui um espaço para tabela dedicado a cada sessão que cria uma tabela temporária. Esse espaço para tabela permanece ativo até que a conexão com o banco de dados termine. Para gerenciar seus recursos com maior eficiência: + Implemente o agrupamento de conexões para limitar o número de espaços para tabelas temporários ativos. + Reutilize as conexões existentes em vez de criar outras para cada operação.