# synch/mutex/innodb/trx\$1sys\$1mutex
<a name="ams-waits.trxsysmutex"></a>

O evento `synch/mutex/innodb/trx_sys_mutex` ocorre quando há alta atividade de banco de dados com muitas transações.

**Topics**
+ [Versões de mecanismos relevantes](#ams-waits.trxsysmutex.context.supported)
+ [Contexto](#ams-waits.trxsysmutex.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.trxsysmutex.causes)
+ [Ações](#ams-waits.trxsysmutex.actions)

## Versões de mecanismos relevantes
<a name="ams-waits.trxsysmutex.context.supported"></a>

Essas informações de eventos de espera têm suporte nas seguintes versões do mecanismo:
+ Aurora MySQL versões 2 e 3

## Contexto
<a name="ams-waits.trxsysmutex.context"></a>

Internamente, o mecanismo de banco de dados InnoDB utiliza o nível de isolamento de leitura repetível com snapshots para fornecer consistência de leitura. Isso fornece uma visão pontual do banco de dados na ocasião em que o snapshot foi criado.

No InnoDB, todas as alterações são aplicadas ao banco de dados logo que chegam, independentemente de terem sido confirmadas ou não. Essa abordagem significa que, sem o controle de simultaneidade de várias versões (MVCC), todos os usuários conectados ao banco de dados visualizam todas as alterações e as linhas mais recentes. Portanto, o InnoDB requer uma maneira de acompanhar as alterações para saber o que deve ser revertido quando necessário.

Para fazer isso, o InnoDB utiliza um sistema de transações (`trx_sys`) para acompanhar snapshots. Esse sistema de transações faz o seguinte:
+ Acompanha o ID da transação para cada linha nos logs de operações desfazer.
+ Usa uma estrutura interna do InnoDB denominada `ReadView`, que ajuda a identificar quais IDs de transação estão visíveis para um snapshot.

## Possíveis causas do maior número de esperas
<a name="ams-waits.trxsysmutex.causes"></a>

Qualquer operação de banco de dados que exija manuseio consistente e controlado (criação, leitura, atualização e exclusão) de IDs de transações gera uma chamada de `trx_sys` para o mutex.

Essas chamadas acontecem dentro de três funções:
+ `trx_sys_mutex_enter` – Cria o mutex.
+ `trx_sys_mutex_exit` – Libera o mutex.
+ `trx_sys_mutex_own` – Testa se existe uma propriedade para o mutex.

A instrumentação do Performance Schema do InnoDB rastreia todas as chamadas de mutex `trx_sys`. O acompanhamento inclui, mas não se limita a, o gerenciamento de `trx_sys` na inicialização ou encerramento do banco de dados, operações de reversão, limpezas de operações desfazer, acesso de leitura de linha e cargas de grupo de buffer. A alta atividade do banco de dados com um grande número de transações resulta no surgimento de `synch/mutex/innodb/trx_sys_mutex` entre os principais eventos de espera.

Para saber mais, consulte o tópico sobre como [Monitorar esperar de mutex do InnoDB utilizando o Performance Schema](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html), na documentação do MySQL.

## Ações
<a name="ams-waits.trxsysmutex.actions"></a>

Recomenda-se ações distintas, dependendo dos motivos do evento de espera.

**Topics**
+ [Identificar as sessões e as consultas que estão causando os eventos](#ams-waits.trxsysmutex.actions.identify)
+ [Examinar outros eventos de espera](#ams-waits.trxsysmutex.actions.action1)

### Identificar as sessões e as consultas que estão causando os eventos
<a name="ams-waits.trxsysmutex.actions.identify"></a>

Em geral, bancos de dados com carga de moderada a significativa apresentam eventos de espera. Os eventos de espera podem ser aceitáveis quando a performance é ideal. Se a performance não for ideal, examine onde o banco de dados está passando a maior parte do tempo. Observe os eventos de espera que contribuem para a carga mais alta. Descubra se é possível otimizar o banco de dados e a aplicação para reduzir esses eventos.

**Para visualizar o gráfico Top SQL (SQL principal) no Console de gerenciamento da AWS**

1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. No painel de navegação, escolha **Performance Insights**.

1. Escolha uma instância de banco de dados. O painel do Performance Insights é exibido para essa instância de banco de dados.

1. No gráfico **Database load** (Carga de banco de dados), escolha **Slice by wait** (Segmentar por espera).

1. Abaixo do gráfico **Database load** (Carga de banco de dados), escolha **Top SQL** (SQL principal).

   O gráfico mostra as consultas SQL que são responsáveis pela carga. Os que estão no topo da lista são os mais responsáveis. Para solucionar um gargalo, concentre-se nessas instruções.

Para obter uma visão geral útil da solução de problemas de uso do Performance Insights, consulte a Publicação no blog sobre como [Analisar workloads do Amazon Aurora MySQL com o Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).

### Examinar outros eventos de espera
<a name="ams-waits.trxsysmutex.actions.action1"></a>

Examine os outros eventos de espera associados ao evento de espera `synch/mutex/innodb/trx_sys_mutex`. Isso pode fornecer mais informações sobre a natureza da workload. Um número elevado de transações pode reduzir a taxa de transferência, mas a workload também pode tornar isso necessário.

Para obter mais informações sobre como otimizar transações, consulte o tópico sobre como [Otimizar o gerenciamento de transações do InnoDB](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html), na documentação do MySQL.