Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

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

L’evento `synch/sxlock/innodb/hash_table_locks` si verifica quando le pagine non trovate nel pool di buffer devono essere lette dall’archiviazione.

**Topics**
+ [Versioni del motore supportate](#ams-waits.sx-lock-hash-table-locks.context.supported)
+ [Contesto](#ams-waits.sx-lock-hash-table-locks.context)
+ [Probabili cause di aumento delle attese](#ams-waits.sx-lock-hash-table-locks.causes)
+ [Azioni](#ams-waits.sx-lock-hash-table-locks.actions)

## Versioni del motore supportate
<a name="ams-waits.sx-lock-hash-table-locks.context.supported"></a>

Queste informazioni sull’evento di attesa sono supportate per le seguenti versioni:
+ Aurora MySQL versioni 2 e 3

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

L’evento `synch/sxlock/innodb/hash_table_locks` indica che un carico di lavoro accede frequentemente a dati che non sono memorizzati nel pool di buffer. Questo evento di attesa è associato ad aggiunte di nuove pagine e a espulsioni di dati vecchi dal pool di buffer. I dati memorizzati nei dati nuovi e vecchi del pool di buffer devono essere memorizzati nella cache, in modo che le pagine vecchie vengano espulse per consentire la memorizzazione nella cache delle nuove pagine. MySQL utilizza un algoritmo utilizzato meno di recente (LRU) per espellere pagine dal pool di buffer. Il carico di lavoro sta tentando di accedere ai dati che non sono stati caricati nel pool di buffer o ai dati che sono stati espulsi dal pool di buffer.

Questo evento di attesa si verifica quando il carico di lavoro deve accedere ai dati nei file su disco o quando i blocchi vengono liberati o aggiunti all’elenco LRU del pool di buffer. Queste operazioni attendono di ottenere un blocco condiviso escluso (SX-Lock). Questo SX-Lock viene utilizzato per la sincronizzazione su *tabella hash*, che è una tabella in memoria progettata per migliorare le prestazioni di accesso al pool di buffer.

Per ulteriori informazioni, consulta [Pool di buffer](https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html) nella documentazione di MySQL.

## Probabili cause di aumento delle attese
<a name="ams-waits.sx-lock-hash-table-locks.causes"></a>

Quando l’evento di attesa `synch/sxlock/innodb/hash_table_locks` appare più che normale, probabilmente indicando un problema di prestazioni, le cause tipiche includono le seguenti:

**Un pool di buffer sottodimensionato**  
La dimensione del pool di buffer è troppo piccola per mantenere in memoria tutte le pagine a cui si accede di frequente.

**Carico di lavoro pesante**  
Il carico di lavoro sta causando frequenti espulsioni e ricariche di pagine di dati nella cache del buffer.

**Errori di lettura delle pagine**  
Ci sono errori di lettura delle pagine nel pool di buffer, che potrebbero indicare il danneggiamento dei dati.

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

Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.

**Topics**
+ [Aumenta le dimensioni del pool del buffer](#ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size)
+ [Miglioramento dei modelli di accesso ai dati](#ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns)
+ [Riduci o evita le scansioni complete della tabella](#ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans)
+ [Controllare i registri degli errori per la presenza del danneggiamento della pagina](#ams-waits.sx-lock-hash-table-locks.actions.check-error-logs)

### Aumenta le dimensioni del pool del buffer
<a name="ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size"></a>

Assicurarsi che il pool del buffer sia ridimensionato in modo appropriato per il carico di lavoro. Per farlo è possibile controllare la percentuale di riscontri nella cache del pool di buffer. In genere, se il valore scende al di sotto del 95%, è consigliabile aumentare la dimensione del pool di buffer. Un pool di buffer più ampio può mantenere più a lungo in memoria le pagine a cui si accede di frequente. Per aumentare le dimensioni del pool di buffer, modificare il valore del parametro `innodb_buffer_pool_size`. Il valore predefinito di questo parametro è basato sulle dimensioni della classe di istanza database. Per ulteriori informazioni, consulta [Best practice per la configurazione del database di Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/).

### Miglioramento dei modelli di accesso ai dati
<a name="ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns"></a>

Controlla le query interessate da questa attesa e i relativi piani di esecuzione. Considera la possibilità di migliorare i modelli di accesso ai dati. Ad esempio, se si sta utilizzando[mysqli\$1result:: fetch\$1array](https://www.php.net/manual/en/mysqli-result.fetch-array.php), si può provare ad aumentare la dimensione del recupero dell’array.

È possibile utilizzare Performance Insights per visualizzare query e sessioni che potrebbero causare l’evento di attesa `synch/sxlock/innodb/hash_table_locks`.

**Per trovare query di SQL responsabili del carico elevato**

1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all’indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Nel pannello di navigazione scegli **Approfondimenti sulle prestazioni**.

1. Scegli un’istanza database. Viene visualizzato il pannello di controllo di Approfondimenti sulle prestazioni per l’istanza database.

1. Nel grafico **Carico del database**, scegli **Dividi per attesa**.

1. Nella parte inferiore della pagina scegli **Prime Instruzioni SQL**.

   Il grafico elenca le query di SQL responsabili del carico. Quelli in cima all’elenco sono le più responsabili. Per risolvere un collo di bottiglia, occorre concentrarsi su queste istruzioni.

Per una panoramica utile dell’identificazione e della risoluzione dei problemi con Performance Insights, consulta il post del blog AWS [Analizza i carichi di lavoro di Amazon Aurora MySQL con Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).

### Riduci o evita le scansioni complete della tabella
<a name="ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans"></a>

Monitora il carico di lavoro per verificare se sta eseguendo scansioni a tabella completa e, in caso affermativo, ridurle o evitarle. Ad esempio, è possibile monitorare le variabili di stato come ad esempio `Handler_read_rnd_next`. Per ulteriori dettagli, consulta [Variabili dello stato del server](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Handler_read_rnd_next) nella documentazione di MySQL.

### Controllare i registri degli errori per la presenza del danneggiamento della pagina
<a name="ams-waits.sx-lock-hash-table-locks.actions.check-error-logs"></a>

È possibile controllare il mysql-error.log per la presenza di messaggi correlati al danneggiamento che sono stati rilevati in prossimità del momento in cui si è verificato il problema. I messaggi con cui è possibile lavorare per risolvere il problema si trovano nel registro degli errori. Potrebbe essere necessario ricreare oggetti segnalati come danneggiati.