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à.

# io/table/sql/handler
<a name="ams-waits.waitio"></a>

L’evento `io/table/sql/handler` si verifica quando il lavoro è stato delegato a un motore di archiviazione.

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

## Versioni del motore supportate
<a name="ams-waits.waitio.context.supported"></a>

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

## Contesto
<a name="ams-waits.waitio.context"></a>

L’evento `io/table` indica un’attesa per l’accesso a una tabella. Questo evento si verifica indipendentemente dal fatto che i dati siano memorizzati nella cache nel pool di buffer o se si acceda su disco. L’evento `io/table/sql/handler` indica un aumento dell’attività del carico di lavoro. 

Un *handler* è una routine specializzata in un determinato tipo di dati o incentrata su determinate attività speciali. Ad esempio, un handler di eventi riceve e digerisce eventi e segnali dal sistema operativo o da un’interfaccia utente. Un handler di memoria esegue processi relativi alla memoria. Un handler di input di file è una funzione che riceve l’input di file ed esegue attività speciali sui dati, in base al contesto.

Visualizzazioni come `performance_schema.events_waits_current` spesso mostrano `io/table/sql/handler` quando l’attesa effettiva è un evento di attesa annidato come un blocco. Quando l’attesa effettiva non è `io/table/sql/handler`, Approfondimenti sulle prestazioni segnala l’evento di attesa annidato. Quando Performance Insights riporta`io/table/sql/handler`, rappresenta l'elaborazione della I/O richiesta da parte di InnoDB e non un evento di attesa annidato nascosto. Per ulteriori informazioni consulta [Performance Schema Atom and Molecule Events](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) nel *Manuale di riferimento di MySQL*.

L'`io/table/sql/handler`evento compare spesso tra gli eventi di maggiore attesa con I/O attese come. `io/aurora_redo_log_flush`

## Probabili cause di aumento delle attese
<a name="ams-waits.waitio.causes"></a>

In Approfondimenti sulle prestazioni, picchi improvvisi nell’evento `io/table/sql/handler` indicano un aumento dell’attività del carico di lavoro. Aumento dell’attività significa un aumento dell’I/O. 

Performance Insights filtra l'evento di nidificazione IDs e non segnala un'`io/table/sql/handler`attesa quando l'evento nidificato sottostante è un'attesa di blocco. Ad esempio, se l’evento causa principale è [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md), Approfondimenti sulle prestazioni visualizza questa attesa nei primi eventi di attesa e non `io/table/sql/handler`.

In visualizzazioni come `performance_schema.events_waits_current`, le attese di `io/table/sql/handler` spesso appaiono quando l’attesa effettiva è un evento di attesa annidato come un blocco. Quando l’attesa effettiva è diversa da `io/table/sql/handler`, Approfondimenti sulle prestazioni cerca l’attesa annidata e segnala l’attesa effettiva anziché `io/table/sql/handler`. Quando Approfondimenti sulle prestazioni segnala `io/table/sql/handler`, la vera attesa è `io/table/sql/handler` e non un evento di attesa annidato nascosto. Per ulteriori informazioni consulta [Performance Schema Atom and Molecule Events](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) nel *Manuale di riferimento di MySQL 5.7*.

## Azioni
<a name="ams-waits.waitio.actions"></a>

Se l’evento di attesa domina l’attività del database, non indica necessariamente un problema di prestazioni. Un evento di attesa è sempre in primo piano quando il database è attivo. È necessario agire solo quando le prestazioni diminuiscono.

Consigliamo azioni diverse a seconda degli altri eventi di attesa visualizzati.

**Topics**
+ [Identificare le sessioni e le query che causano gli eventi](#ams-waits.waitio.actions.identify)
+ [Verifica la presenza di una correlazione con i parametri dei contatori di Approfondimenti sulle prestazioni](#ams-waits.waitio.actions.filters)
+ [Verifica la presenza di altri eventi di attesa correlati](#ams-waits.waitio.actions.maintenance)

### Identificare le sessioni e le query che causano gli eventi
<a name="ams-waits.waitio.actions.identify"></a>

In genere, i database con carico da moderato a significativo hanno eventi di attesa. Gli eventi di attesa possono essere accettabili se le prestazioni sono ottimali. Se le prestazioni non sono ottimali, esaminare dove il database impiega più tempo. Considerare gli eventi di attesa che contribuiscono al carico più elevato per scoprire se è possibile ottimizzare il database e l’applicazione per ridurre tali eventi.

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

1. Accedi a 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 Approfondimenti sulle prestazioni, consulta il post del blog[Analizza i carichi di lavoro di Amazon Aurora MySQL con Approfondimenti sulle prestazioni](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).

### Verifica la presenza di una correlazione con i parametri dei contatori di Approfondimenti sulle prestazioni
<a name="ams-waits.waitio.actions.filters"></a>

Verifica la presenza di parametri del contatore di Approfondimenti sulle prestazioni come `Innodb_rows_changed`. Se i parametri del contatore sono correlati con `io/table/sql/handler`, segui questi passaggi:

1. In Approfondimenti sulle prestazioni, cerca le istruzioni SQL che rappresentano l’evento di attesa principale `io/table/sql/handler`. Se possibile, ottimizza questa istruzione in modo che restituisca un numero inferiore di righe.

1. Recupera le tabelle principali dalle visualizzazione `schema_table_statistics` e `x$schema_table_statistics`. Queste visualizzazioni mostrano la quantità di tempo impiegato per tabella. Per ulteriori informazioni, consulta [Le visualizzazioni schema\$1table\$1statistics e x\$1schema\$1table\$1statistics](https://dev.mysql.com/doc/refman/5.7/en/sys-schema-table-statistics.html) nel *Manuale di riferimento di MySQL*.

   Per impostazione predefinita, le righe vengono ordinate in base al tempo di attesa totale discendente. Le tabelle con il maggior numero di contese appaiono per prime. L’output indica se il tempo viene impiegato per le letture, le scritture, il recupero, gli inserimenti, gli aggiornamenti o le eliminazioni.

   ```
   mysql> select * from sys.schema_table_statistics limit 1\G
   
   *************************** 1. row ***************************
        table_schema: read_only_db
          table_name: sbtest41
       total_latency: 54.11 m
        rows_fetched: 6001557
       fetch_latency: 39.14 m
       rows_inserted: 14833
      insert_latency: 5.78 m
        rows_updated: 30470
      update_latency: 5.39 m
        rows_deleted: 14833
      delete_latency: 3.81 m
    io_read_requests: NULL
             io_read: NULL
     io_read_latency: NULL
   io_write_requests: NULL
            io_write: NULL
    io_write_latency: NULL
    io_misc_requests: NULL
     io_misc_latency: NULL
   1 row in set (0.11 sec)
   ```

### Verifica la presenza di altri eventi di attesa correlati
<a name="ams-waits.waitio.actions.maintenance"></a>

Se `synch/sxlock/innodb/btr_search_latch` e `io/table/sql/handler` insieme contribuiscono maggiormente all’anomalia del carico del database, verificare se la variabile `innodb_adaptive_hash_index` è attivata. Se lo è, considera la possibilità di aumentare il valore del parametro `innodb_adaptive_hash_index_parts`.

Se l’indice adattivo Hash è disattivato, considera la possibilità di attivarlo. Per ulteriori informazioni sull’indice adattivo Hash di MySQL, consulta le seguenti risorse:
+ L’articolo [L’indice adattivo Hash in InnoDB è adatto al mio carico di lavoro?](https://www.percona.com/blog/2016/04/12/is-adaptive-hash-index-in-innodb-right-for-my-workload) sul sito web di Percona
+ [Indice adattivo Hash](https://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html) nel *Manuale di riferimento di MySQL*
+ L’articolo [Contesa in MySQL InnoDB: informazioni utili dalla sezione Segnalazioni](https://www.percona.com/blog/2019/12/20/contention-in-mysql-innodb-useful-info-from-the-semaphores-section/) sul sito web di Percona

**Nota**  
L’indice adattivo Hash non è supportato nelle istanze database di lettura di Aurora.  
In alcuni casi, le prestazioni potrebbero risultare scadenti su un’istanza di lettura quando `synch/sxlock/innodb/btr_search_latch` e `io/table/sql/handler` sono dominanti. In tal caso, prendere in considerazione il reindirizzamento temporaneo del carico di lavoro all’istanza database di scrittura e l’attivazione dell’indice adattivo Hash.