# synch/sxlock/innodb/hash\$1table\$1locks
<a name="ams-waits.sx-lock-hash-table-locks"></a>

O evento `synch/sxlock/innodb/hash_table_locks` ocorre quando as páginas não encontradas no grupo de buffer devem ser lidas do armazenamento.

**Topics**
+ [Versões compatíveis do mecanismo](#ams-waits.sx-lock-hash-table-locks.context.supported)
+ [Contexto](#ams-waits.sx-lock-hash-table-locks.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.sx-lock-hash-table-locks.causes)
+ [Ações](#ams-waits.sx-lock-hash-table-locks.actions)

## Versões compatíveis do mecanismo
<a name="ams-waits.sx-lock-hash-table-locks.context.supported"></a>

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

## Contexto
<a name="ams-waits.sx-lock-hash-table-locks.context"></a>

O evento `synch/sxlock/innodb/hash_table_locks` indica que uma workload está acessando com frequência dados que não estão armazenados no grupo de buffer. Esse evento de espera está associado a novas adições de página e remoções de dados antigos do grupo de buffer. Os dados armazenados no grupo de buffer antigos e os dados novos devem ser armazenados em cache, para que as páginas antigas sejam despejadas de forma a permitir o armazenamento em cache das novas páginas. O MySQL aplica um algoritmo menos utilizado recentemente (LRU) para expulsar páginas do grupo de buffers. A workload está tentando acessar dados que não foram carregados no grupo de buffer ou dados que foram despejados do grupo de buffer.

Esse evento de espera ocorre quando a workload deve acessar os dados em arquivos no disco ou quando os blocos são liberados ou adicionados à lista de LRUs do grupo de buffer. Essas operações esperam até obter um bloqueio excluído compartilhado (SX-lock). Esse SX-lock é utilizado para a sincronização na *tabela de hash*, uma tabela na memória projetada para melhorar a performance do acesso ao grupo de buffer.

Para obter mais informações, consulte o tópico sobre o [Grupo de buffer](https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html), na documentação do MySQL.

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

Quando o evento de espera `synch/sxlock/innodb/hash_table_locks` aparece mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem:

**Um grupo de buffers subdimensionado**  
O tamanho do grupo de buffer é muito pequeno para manter na memória todas as páginas frequentemente acessadas.

**Workload pesada**  
A workload está causando despejos frequentes e recarregamentos de páginas de dados no cache de buffer.

**Erros de leitura das páginas**  
Ocorrem erros ao ler páginas no grupo de buffer, o que pode indicar corrupção dos dados.

## Ações
<a name="ams-waits.sx-lock-hash-table-locks.actions"></a>

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

**Topics**
+ [Aumentar o tamanho do grupo de buffer](#ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size)
+ [Melhorar padrões de acesso a dados](#ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns)
+ [Reduzir ou evitar varreduras de tabelas inteiras](#ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans)
+ [Verificar se há páginas corrompidas nos logs de erros](#ams-waits.sx-lock-hash-table-locks.actions.check-error-logs)

### Aumentar o tamanho do grupo de buffer
<a name="ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size"></a>

Certifique-se de que o grupo de buffer esteja apropriadamente escalado para a workload. Para isso, é possível verificar a taxa de acertos do cache do grupo de buffer. Em geral, se o valor cair abaixo de 95%, considere aumentar o tamanho do grupo de buffer. Um grupo de buffer maior pode manter por mais tempo na memória as páginas acessadas com frequência. Para aumentar o tamanho do grupo de buffer, modifique o valor do parâmetro `innodb_buffer_pool_size`. O valor padrão desse parâmetro baseia-se no tamanho da classe da instância de banco de dados. Para obter mais informações, consulte [Práticas recomendadas para a configuração do banco de dados do Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/).

### Melhorar padrões de acesso a dados
<a name="ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns"></a>

Confira as consultas afetadas por essa espera e seus planos de execução. Considere melhorar padrões de acesso a dados. Por exemplo, se você estiver utilizando [mysqli\$1result::fetch\$1array](https://www.php.net/manual/en/mysqli-result.fetch-array.php), poderá tentar aumentar o tamanho da busca das matrizes.

É possível utilizar o Performance Insights para mostrar consultas e sessões que possam estar causando o evento de espera `synch/sxlock/innodb/hash_table_locks`.

**Para localizar consultas SQL que são responsáveis pela carga alta**

1. Faça login no Console de gerenciamento da AWS e 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. Na parte inferior da página, 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 AWSPublicação no blog de banco de dados 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/).

### Reduzir ou evitar varreduras de tabelas inteiras
<a name="ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans"></a>

Monitore sua workload para ver se ela está executando varreduras de tabelas inteiras e, se estiver, reduza ou evite essas varreduras. Por exemplo, é possível monitorar variáveis de status como `Handler_read_rnd_next`. Para obter mais informações, consulte o tópico sobre [Variáveis de status do servidor](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Handler_read_rnd_next), na documentação do MySQL.

### Verificar se há páginas corrompidas nos logs de erros
<a name="ams-waits.sx-lock-hash-table-locks.actions.check-error-logs"></a>

É possível consultar mysql-error.log em busca de mensagens relacionadas a corrupções que foram detectadas perto do momento do problema. As mensagens com as quais é possível trabalhar para solucionar o problema estão no log de erros. Talvez seja necessário recriar objetos que foram sinalizados como corrompidos.