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à.
# Ottimizzazione di Aurora MySQL
Gli eventi di attesa e gli stati di thread sono un importante strumento di ottimizzazione per Aurora MySQL. Se si riesce a scoprire perché le sessioni stanno aspettando risorse e cosa stanno facendo, è possibile ridurre meglio i colli di bottiglia. È possibile utilizzare le informazioni contenute in questa sezione per trovare possibili cause e azioni correttive.
Amazon DevOps Guru per RDS è in grado di determinare in modo proattivo se i database Aurora MySQL presentano condizioni problematiche che potrebbero causare problemi più seri in seguito. Amazon DevOps Guru per RDS pubblica una spiegazione e i suggerimenti per le azioni correttive negli approfondimenti proattivi. Questa sezione contiene gli approfondimenti per i problemi più comuni.
**Importante**
Gli eventi di attesa e gli stati del thread in questa sezione sono specifici di Aurora MySQL. Utilizza le informazioni contenute in questa sezione per regolare solo Amazon Aurora, non Amazon RDS for MySQL.
Alcuni eventi di attesa in questa sezione non hanno analoghi nelle versioni open source di questi motori di database. Altri eventi di attesa hanno gli stessi nomi degli eventi nei motori open source, ma si comportano in modo diverso. Ad esempio, l'archiviazione di Amazon Aurora funziona in modo diverso dall'archiviazione open source, pertanto gli eventi di attesa correlati all'archiviazione indicano condizioni di risorse differenti.
**Topics**
+ [Concetti essenziali per la regolazione di Aurora MySQL](AuroraMySQL.Managing.Tuning.concepts.md)
+ [Regolazione di Aurora MySQL con eventi di attesa](AuroraMySQL.Managing.Tuning.wait-events.md)
+ [Regolazione di Aurora MySQL con stati del thread](AuroraMySQL.Managing.Tuning.thread-states.md)
+ [Ottimizzazione di Aurora MySQL con approfondimenti proattivi di Amazon DevOps Guru](MySQL.Tuning.proactive-insights.md)
# Concetti essenziali per la regolazione di Aurora MySQL
Prima di regolare il database di Aurora MySQL, assicurati di sapere quali sono gli eventi di attesa e gli stati del thread e perché si verificano. Esaminare anche l'architettura di base della memoria e del disco di Aurora MySQL quando si utilizza il motore di archiviazione InnoDB. Per un utile diagramma architettonico, consulta il[Manuale di riferimento MySQL](https://dev.mysql.com/doc/refman/8.0/en/innodb-architecture.html).
**Topics**
+ [Eventi di attesa di Aurora MySQL](#AuroraMySQL.Managing.Tuning.concepts.waits)
+ [Stati del thread di Aurora MySQL](#AuroraMySQL.Managing.Tuning.concepts.thread-states)
+ [Memoria di Aurora MySQL](#AuroraMySQL.Managing.Tuning.concepts.memory)
+ [Procedure di Aurora MySQL](#AuroraMySQL.Managing.Tuning.concepts.processes)
## Eventi di attesa di Aurora MySQL
Un *evento di attesa* indica una risorsa per la quale è in attesa una sessione. Ad esempio, l'evento di attesa `io/socket/sql/client_connection` indica che un thread sta per gestire una nuova connessione. Le risorse tipiche che una sessione attende includono quanto segue:
+ Accesso a thread singolo a un buffer, ad esempio, quando una sessione sta tentando di modificare un buffer
+ Una riga attualmente bloccata da un'altra sessione
+ Un file di dati letto
+ Scrittura di un file log
Ad esempio, per soddisfare una query, la sessione potrebbe eseguire una scansione completa della tabella. Se i dati non sono già in memoria, la sessione attende il completamento dell'I/O del disco. Quando i buffer vengono letti in memoria, potrebbe essere necessario attendere perché altre sessioni accedono agli stessi buffer. Il database registra le attese utilizzando un evento di attesa predefinito. Questi eventi sono raggruppati in categorie.
Un evento di attesa non mostra di per sé un problema di prestazioni. Ad esempio, se i dati richiesti non sono in memoria, è necessaria la lettura dei dati dal disco. Se una sessione blocca una riga per un aggiornamento, un'altra sessione attende che la riga venga sbloccata in modo che possa aggiornarla. Un commit richiede di attendere il completamento della scrittura su un file di registro. Le attese sono parte integrante del normale funzionamento di un database.
Un gran numero di eventi di attesa in genere mostrano un problema di prestazioni. In questi casi, è possibile utilizzare i dati degli eventi di attesa per determinare dove stanno trascorrendo il tempo delle sessioni. Ad esempio, se un report che in genere viene eseguito in minuti ora viene eseguito per ore, è possibile identificare gli eventi di attesa che contribuiscono maggiormente al tempo di attesa totale. Se è possibile determinare le cause degli eventi di attesa principali, a volte è possibile apportare modifiche che migliorano le prestazioni. Ad esempio, se la sessione è in attesa su una riga bloccata da un'altra sessione, è possibile terminare la sessione di blocco.
## Stati del thread di Aurora MySQL
Uno *stato generale del thread* è un valore `State` associato all'elaborazione generale delle query. Ad esempio, lo stato del thread `sending data` indica che un thread sta leggendo e filtrando le righe per una query per determinare il set di risultati corretto.
Puoi usare gli stati del thread per regoalre Aurora MySQL in modo simile a come usi gli eventi di attesa. Ad esempio, frequenti occorrenze di `sending data` di solito indicano che una query non utilizza un indice. Per ulteriori informazioni sugli stati del thread, consulta [Stati generali del thread](https://dev.mysql.com/doc/refman/5.7/en/general-thread-states.html) nel *Manuale di riferimento di MySQL*.
Quando si utilizza Performance Insights, è vera una delle seguenti condizioni:
+ Performance Schema è attivato: Aurora MySQL mostra gli eventi di attesa anziché lo stato del thread.
+ Performance Schema non è attivato: Aurora MySQL mostra lo stato del thread.
Consigliamo di configurare il Performance Schema per la gestione automatica. Il Performance Schema fornisce ulteriori informazioni dettagliate e strumenti migliori per indagare sui potenziali problemi di prestazioni. Per ulteriori informazioni, consulta [Panoramica dello schema di prestazioni per Approfondimenti sulle prestazioni su Aurora MySQL](USER_PerfInsights.EnableMySQL.md).
## Memoria di Aurora MySQL
In Aurora MySQL, le aree di memoria più importanti sono il pool di buffer e il buffer di registro.
**Topics**
+ [Pool di buffer](#AuroraMySQL.Managing.Tuning.concepts.memory.buffer-pool)
### Pool di buffer
Il *pool di buffer* è l'area di memoria condivisa in cui Aurora MySQL memorizza nella cache i dati di tabella e indice. Le query possono accedere ai dati utilizzati di frequente direttamente dalla memoria senza leggere dal disco.
Il pool di buffer è strutturato come un elenco di pagine collegato. Una *pagina* può contenere più righe. Aurora MySQL utilizza un algoritmo utilizzato meno di recente (LRU) per invecchiare le pagine fuori dal pool.
Per ulteriori informazioni, consulta [Buffer Pool](https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html) (Pool di buffer) nel *Manuale di riferimento di MySQL*.
## Procedure di Aurora MySQL
Aurora MySQL utilizza un modello di procedure molto diverso da Aurora PostgreSQL.
**Topics**
+ [Server MySQL (mysqld)](#AuroraMySQL.Managing.Tuning.concepts.processes.mysqld)
+ [Thread](#AuroraMySQL.Managing.Tuning.concepts.processes.threads)
+ [Pool di thread](#AuroraMySQL.Managing.Tuning.concepts.processes.pool)
### Server MySQL (mysqld)
Il server MySQL è una procedura singola del sistema operativo denominato mysqld. Il server MySQL non genera procedure aggiuntive. Pertanto, un database di Aurora MySQL utilizza mysqld per eseguire la maggior parte del suo lavoro.
Quando si avvia il server MySQL, ascolta le connessioni di rete dai client MySQL. Quando un client si connette al database, mysqld apre un thread.
### Thread
I thread del gestore delle connessioni associano ogni connessione client a un thread dedicato. Questo thread gestisce l'autenticazione, esegue istruzioni e restituisce i risultati al client. Il gestore delle connessioni crea nuovi thread quando necessario.
La *cache dei thread* è il set di thread disponibili. Quando una connessione termina, MySQL restituisce il thread alla cache del thread se la cache non è piena. La variabile del sistema `thread_cache_size` determina la dimensione della cache del thread.
### Pool di thread
Il *pool di thread* è costituito da un certo numero di gruppi di thread. Ogni gruppo gestisce una serie di connessioni client. Quando un client si connette al database, il pool di thread assegna le connessioni ai gruppi di thread in modo round-robin. Il pool di thread separa connessioni e thread. Non esiste una relazione fissa tra le connessioni e i thread che eseguono istruzioni ricevute da tali connessioni.
# Regolazione di Aurora MySQL con eventi di attesa
La tabella seguente riassume gli eventi di attesa di Aurora MySQL che più comunemente indicano problemi di prestazioni. I seguenti eventi di attesa sono un sottoinsieme dell'elenco in [Eventi di attesa Aurora MySQL](AuroraMySQL.Reference.Waitevents.md).
| Evento di attesa | Description |
| --- | --- |
| [cpu](ams-waits.cpu.md) | Questo evento si verifica quando un thread è attivo nella CPU o è in attesa della CPU. |
| [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md) | Questo evento si verifica quando una sessione sta scrivendo dati permanenti nell'archiviazione di Aurora. |
| [io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md) | Questo evento si verifica quando un thread è in attesa di restituire una serie di risultati a un client. |
| [io/redo\$1log\$1flush](ams-waits.io-redologflush.md) | Questo evento si verifica quando una sessione sta scrivendo dati permanenti nell'archiviazione di Aurora. |
| [io/socket/sql/client\$1connessione](ams-waits.client-connection.md) | Questo evento si verifica quando un thread sta per gestire una nuova connessione. |
| [io/table/sql/handler](ams-waits.waitio.md) | Questo evento si verifica quando il lavoro è stato delegato a un motore di archiviazione. |
| [synch/cond/innodb/row\$1blocca\$1aspetta](ams-waits.row-lock-wait.md) | Questo evento si verifica quando una sessione ha bloccato una riga per un aggiornamento e un'altra sessione tenta di aggiornare la stessa riga. |
| [synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md) | Questo evento si verifica quando una sessione ha bloccato una riga per un aggiornamento e un'altra sessione tenta di aggiornare la stessa riga. |
| [synch/cond/sql/MDL\$1contesto: :COND\$1WAIT\$1STATUS](ams-waits.cond-wait-status.md) | Questo evento si verifica quando ci sono thread in attesa del blocco dei metadati di una tabella. |
| [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md) | Questo evento si verifica quando una sessione ha bloccato una riga per un aggiornamento e un'altra sessione tenta di aggiornare la stessa riga. |
| [synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md) | Questo evento si verifica quando un thread ha acquisito un blocco nel pool di buffer InnoDB per accedere a una pagina in memoria. |
| [synch/mutex/innodb/fil\$1sistema\$1mutex](ams-waits.innodb-fil-system-mutex.md) | Questo evento si verifica quando una sessione è in attesa di accedere alla cache di memoria del tablespace. |
| [synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md) | Questo evento si verifica quando c'è un'elevata attività del database con un numero elevato di transazioni. |
| [synch/sxlock/innodb/hash\$1table\$1locks](ams-waits.sx-lock-hash-table-locks.md) | Questo evento si verifica quando le pagine non trovate nel pool del buffer devono essere lette da un file. |
| [synch/mutex/innodb/temp\$1pool\$1manager\$1mutex](ams-waits.io-temppoolmanager.md) | Questo evento si verifica quando una sessione è in attesa di acquisire un mutex per la gestione del pool di tablespace temporanee della sessione. |
# cpu
L’evento di attesa `cpu` si verifica quando un thread è attivo nella CPU o è in attesa della CPU.
**Topics**
+ [Versioni del motore supportate](#ams-waits.cpu.context.supported)
+ [Contesto](#ams-waits.cpu.context)
+ [Probabili cause di aumento delle attese](#ams-waits.cpu.causes)
+ [Azioni](#ams-waits.cpu.actions)
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versioni 2 e 3
## Contesto
Per ogni vCPU, una connessione può eseguire operazioni su questa CPU. In alcune situazioni, il numero di connessioni attive pronte per l'esecuzione è superiore al numero di vCPUs. Questo squilibrio fa sì che le connessioni attendano le risorse della CPU. Se il numero di connessioni attive rimane costantemente superiore al numero di vCPUs, l'istanza presenta un conflitto di CPU. La contesa provoca il verificarsi dell’evento di attesa `cpu`.
**Nota**
Il parametro di Performance Insights per la CPU è `DBLoadCPU`. Il valore per `DBLoadCPU` può differire dal valore della CloudWatch metrica`CPUUtilization`. Quest'ultima metrica viene raccolta da HyperVisor per un'istanza di database.
I parametri del sistema operativo del Performance Insights forniscono informazioni dettagliate sull'utilizzo della CPU. Ad esempio, puoi visualizzare i seguenti parametri:
+ `os.cpuUtilization.nice.avg`
+ `os.cpuUtilization.total.avg`
+ `os.cpuUtilization.wait.avg`
+ `os.cpuUtilization.idle.avg`
Performance Insights segnala l'utilizzo della CPU da parte del motore del database come `os.cpuUtilization.nice.avg`.
## Probabili cause di aumento delle attese
Quando questo evento si verifica più del normale, eventualmente indicando un problema di prestazioni, le cause tipiche includono le seguenti:
+ Query analitiche
+ Transazioni altamente simultanee
+ Transazioni di lunga durata
+ Un improvviso aumento del numero di connessioni, noto come *storm di login*
+ Un aumento del cambio di contesto
## Azioni
Se l’evento di attesa `cpu` domina l'attività del database, non indica necessariamente un problema di prestazioni. Rispondi a questo evento solo quando le prestazioni diminuiscono.
A seconda della causa dell'aumento dell'utilizzo della CPU, considerare le seguenti strategie:
+ Aumenta la capacità della CPU dell'host. Questo approccio tipicamente offre un sollievo temporaneo.
+ Identifica le principali query per una potenziale ottimizzazione.
+ Reindirizza alcuni carichi di lavoro di sola lettura verso i nodi del lettore, se applicabile.
**Topics**
+ [Identifica le sessioni o le query che causano il problema](#ams-waits.cpu.actions.az-vpc-subnet)
+ [Analizza e ottimizza l'elevato carico di lavoro della CPU](#ams-waits.cpu.actions.db-instance-class)
### Identifica le sessioni o le query che causano il problema
Per trovare le sessioni e le query, guarda la tabella **Prime istruzioni SQL** in Performance Insights per le istruzioni SQL che hanno il carico più alto della CPU. Per ulteriori informazioni, consulta [Analisi delle metriche utilizzando il pannello di controllo Performance Insights](USER_PerfInsights.UsingDashboard.md).
In genere, una o due istruzioni SQL consumano la maggior parte dei cicli della CPU. Concentra gli sforzi su queste istruzioni. Supponiamo che l'istanza DB abbia 2 v CPUs con un carico DB di 3,1 sessioni attive medie (AAS), tutte nello stato della CPU. In questo caso, la tua istanza è associata alla CPU. Considera le strategie seguenti:
+ Esegui l'upgrade a una classe di istanze più grande con più vCPUs.
+ Regola le query per ridurre il carico della CPU.
In questo esempio, le query SQL principali hanno un carico del database di 1,5 AAS, il tutto nello stato della CPU. Un'altra istruzione SQL ha un carico di 0,1 nello stato della CPU. In questo esempio, se si è interrotta l'istruzione SQL con caricamento più basso, non si riduce in modo significativo il carico del database. Tuttavia, se si regolano le due query ad alto carico in modo che siano due volte più efficienti, si elimina il collo di bottiglia della CPU. Se si riduce il carico della CPU di 1,5 AAS del 50%, l'AAS per ogni istruzione diminuisce a 0,75. Il carico totale del databalse speso per la CPU è ora di 1,6 AAS. Questo valore è inferiore alla linea massima di vCPU 2.0.
Per una panoramica utile dell’identificazione e della risoluzione dei problemi con Performance Insights, consulta il post del blog[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/). Consulta anche l'articolo di AWS supporto [Come posso risolvere i problemi e risolvere l'utilizzo elevato della CPU sulle mie istanze Amazon RDS for MySQL](https://aws.amazon.com/premiumsupport/knowledge-center/rds-instance-high-cpu/)? .
### Analizza e ottimizza l'elevato carico di lavoro della CPU
Dopo aver identificato la query o le query che aumentano l'utilizzo della CPU, è possibile ottimizzarle o terminare la connessione. L'esempio seguente mostra come terminare una connessione.
```
CALL mysql.rds_kill(processID);
```
Per ulteriori informazioni, consulta [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill).
Se si termina una sessione, l'azione potrebbe innescare un lungo ripristino dello stato precedente.
#### Seguire le linee guida per l'ottimizzazione delle query
Per ottimizzare le query, prendere in considerazione le seguenti linee guida:
+ Eseguire l’istruzione `EXPLAIN`.
Questo comando mostra i singoli passaggi coinvolti nell'esecuzione di una query. Per ulteriori informazioni, consulta [Ottimizzazione delle query con EXPLAIN](https://dev.mysql.com/doc/refman/5.7/en/using-explain.html) nella documentazione di MySQL.
+ Eseguire l’istruzione `SHOW PROFILE`.
Utilizzare questa istruzione per esaminare i dettagli del profilo che possono indicare l'utilizzo delle risorse per le istruzioni eseguite durante la sessione corrente. Per ulteriori informazioni, consulta [Istruzione REPAIR TABLE](https://dev.mysql.com/doc/refman/5.7/en/show-profile.html) nella documentazione di MySQL.
+ Eseguire l’istruzione `ANALYZE TABLE`.
Utilizzare questa istruzione per riaggiornare le statistiche di indice per le tabelle a cui si accede dalla query che consuma CPU elevata. Analizzando l'istruzione, è possibile aiutare l'ottimizzatore a scegliere un piano di esecuzione appropriato. Per ulteriori informazioni, consulta [Istruzione ANALYZE TABLE](https://dev.mysql.com/doc/refman/5.7/en/analyze-table.html) nella documentazione di MySQL.
#### Segui le linee guida per migliorare l'utilizzo della CPU
Per migliorare l'utilizzo della CPU in un'istanza database, attenersi a queste linee guida:
+ Assicurarsi che tutte le query utilizzino indici appropriati.
+ Scopri se è possibile utilizzare query parallele di Aurora. Si può usare questa tecnica per ridurre l'utilizzo della CPU sul nodo head grazie all'elaborazione della funzione di trasferimento, al filtraggio delle righe e alla proiezione delle colonne per la clausola `WHERE`.
+ Scopri se il numero di esecuzioni SQL al secondo soddisfa le soglie previste.
+ Scopri se la manutenzione dell'indice o la creazione di nuovi indici occupano i cicli della CPU necessari per il carico di lavoro di produzione. Pianifica le attività di manutenzione al di fuori degli orari del picco di attività.
+ Scopri se è possibile utilizzare il partizionamento per ridurre la serie dei dati delle query. Per ulteriori informazioni, consultare il post del blog.[Come pianificare e ottimizzare Amazon Aurora con compatibilità MySQL per carichi di lavoro consolidati](https://aws.amazon.com/blogs/database/planning-and-optimizing-amazon-aurora-with-mysql-compatibility-for-consolidated-workloads/).
#### Verifica la presenza di congestioni dovute alla connessione
Se il parametro `DBLoadCPU` non è molto alto, ma il parametro `CPUUtilization` è elevato, la causa dell’utilizzo elevato della CPU risiede al di fuori del motore del database. Un esempio classico è una congestione dovuta alla connessione.
Verificare se le condizioni seguenti sono vere:
+ C'è un aumento sia della metrica Performance Insights che della `CPUUtilization` CloudWatch `DatabaseConnections` metrica Amazon.
+ Il numero di thread nella CPU è maggiore del numero di v. CPUs
Se le condizioni precedenti sono vere, considerare di diminuire il numero di connessioni al database. Ad esempio, è possibile utilizzare un pool di connessione come RDS Proxy. Per conoscere le best practice per una gestione efficace delle connessioni e il dimensionamento, consulta il whitepaper [Manuale di Amazon Aurora MySQL DBA per la gestione delle connessioni](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf).
# io/aurora\$1redo\$1log\$1flush
L’evento `io/aurora_redo_log_flush` si verifica quando una sessione sta scrivendo dati persistenti nell’archiviazione di Amazon Aurora.
**Topics**
+ [Versioni del motore supportate](#ams-waits.io-auredologflush.context.supported)
+ [Contesto](#ams-waits.io-auredologflush.context)
+ [Probabili cause di aumento delle attese](#ams-waits.io-auredologflush.causes)
+ [Azioni](#ams-waits.io-auredologflush.actions)
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 2
## Contesto
L'`io/aurora_redo_log_flush`evento riguarda un'operazione di scrittura input/output (I/O) in Aurora MySQL.
**Nota**
Nella versione 3 di Aurora MySQL, questo evento di attesa è denominato [io/redo\$1log\$1flush.](ams-waits.io-redologflush.md)
## Probabili cause di aumento delle attese
Per la persistenza dei dati, l’esecuzione dei commit richiede una scrittura duratura per un’archiviazione stabile. Se il database esegue troppi commit, c'è un evento di attesa nell' I/O operazione di scrittura, l'evento wait. `io/aurora_redo_log_flush`
Negli esempi seguenti, 50.000 dati vengono inseriti in un cluster di database di Aurora MySQL utilizzando la classe di istanza database db.r5.xlarge:
+ Nel primo esempio, ogni sessione inserisce 10.000 dati riga per riga. Per impostazione predefinita, se un comando del linguaggio di manipolazione dei dati (DML) non si trova all’interno di una transazione, Aurora MySQL utilizza l’esecuzione di commit impliciti. Autocommit è attivo. Ciò significa che per ogni inserimento di riga è presente l’esecuzione di un commit. Performance Insights mostra che le connessioni dedicano la maggior parte del tempo in attesa dell’evento di attesa `io/aurora_redo_log_flush`.
![\[Esempio di Performance Insights dell’evento di attesa\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example1.png)
Ciò è causato dalle semplici istruzioni di inserimento utilizzate.
![\[Inserisci istruzioni in Istruzioni SQL principali\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_top_SQL1.png)
I 50.000 dati richiedono 3,5 minuti per essere inseriti.
+ Nel secondo esempio, gli inserti sono realizzati in 1.000 batch, ovvero ogni connessione esegue 10 commit anziché 10.000. Performance Insights mostra che le connessioni non dedicano la maggior parte del loro tempo sull’evento di attesa `io/aurora_redo_log_flush`.
![\[Esempio di Performance Insights dell’evento di attesa con minore impatto\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example2.png)
I 50.000 dati richiedono 4 secondi per essere inseriti.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
**Topics**
+ [Identificare le sessioni e le query problematiche](#ams-waits.io-auredologflush.actions.identify-queries)
+ [Raggruppa le operazioni di scrittura](#ams-waits.io-auredologflush.actions.action0)
+ [Disattivazione dell'autocommit](#ams-waits.io-auredologflush.actions.action1)
+ [Transazioni di utilizzo](#ams-waits.io-auredologflush.action2)
+ [Utilizza i batch](#ams-waits.io-auredologflush.action3)
### Identificare le sessioni e le query problematiche
Se l'istanza database sta riscontrando un collo di bottiglia, il primo compito è quello di trovare le sessioni e le query che lo causano. Per un utile post sul blog AWS Database, consulta [Analizza i carichi di lavoro MySQL di Amazon Aurora](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) con Performance Insights.
**Per identificare sessioni e query che causano un collo di bottiglia**
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 l'istanza database.
1. In **Carico del database**, scegli **Dividi per attesa**.
1. Nella parte inferiore della pagina scegli **Prime Instruzioni SQL**.
Le query nella parte superiore dell'elenco causano il carico più alto sul database.
### Raggruppa le operazioni di scrittura
Gli esempi seguenti attivano l’evento di attesa `io/aurora_redo_log_flush`. (Autocommit è attivo.)
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
Per ridurre il tempo impiegato in attesa dell’evento di attesa `io/aurora_redo_log_flush`, raggruppa logicamente le operazioni di scrittura in una singola esecuzione di commit per ridurre le chiamate persistenti all’archiviazione.
### Disattivazione dell'autocommit
Disattivare l'autocommit prima di apportare modifiche di grandi dimensioni che non si trovano all'interno di una transazione, come illustrato nell'esempio seguente.
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### Transazioni di utilizzo
È possibile utilizzare le transazioni, come illustrato nell'esempio seguente.
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### Utilizza i batch
Si può anche apportare modifiche in batch, come nell'esempio seguente: Tuttavia, l'utilizzo di batch troppo grandi può causare problemi di prestazioni, specialmente nelle repliche di lettura o durante il point-in-time ripristino (PITR).
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
L’evento `io/aurora_respond_to_client` si verifica quando un thread è in attesa di restituire una serie di risultati a un client.
**Topics**
+ [Versioni del motore supportate](#ams-waits.respond-to-client.context.supported)
+ [Contesto](#ams-waits.respond-to-client.context)
+ [Probabili cause di aumento delle attese](#ams-waits.respond-to-client.causes)
+ [Azioni](#ams-waits.respond-to-client.actions)
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 2
## Contesto
L'evento `io/aurora_respond_to_client` indica che un thread è in attesa di restituire una serie di risultati a un client.
L'elaborazione della query è completa e i risultati vengono restituiti al client dell'applicazione. Tuttavia, poiché non c'è abbastanza larghezza di banda di rete nel cluster del database, un thread è in attesa di restituire la serie di risultati.
## Probabili cause di aumento delle attese
Quando l’evento `io/aurora_respond_to_client` appare più che normale, possibilmente indicando un problema di prestazioni, le cause tipiche includono le seguenti:
**Classe di istanza database insufficiente per il carico di lavoro**
La classe di istanza database utilizzata dal cluster del database non dispone della larghezza di banda di rete necessaria per elaborare il carico di lavoro in modo efficiente.
**Serie di risultati di grandi dimensioni**
Si è verificato un aumento delle dimensioni della serie di risultati restituiti, poiché la query restituisce un numero maggiore di righe. La serie di risultati più ampia consuma una maggiore larghezza di banda di rete.
**Aumento del carico sul client**
Potrebbe esserci pressione della CPU, pressione della memoria o saturazione della rete sul client. Un aumento del carico sul client ritarda la ricezione dei dati dal cluster del database di Aurora MySQL.
**Maggiore latenza di rete**
Potrebbe esserci una maggiore latenza di rete tra il cluster del databalse di Aurora MySQL e il client. Una maggiore latenza di rete aumenta il tempo necessario per il client per la ricezione dei dati.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
**Topics**
+ [Identificare le sessioni e le query che causano gli eventi](#ams-waits.respond-to-client.actions.identify)
+ [Dimensionamento della classe dell’istanza database](#ams-waits.respond-to-client.actions.scale-db-instance-class)
+ [Verifica del carico di lavoro per risultati imprevisti](#ams-waits.respond-to-client.actions.workload)
+ [Distribuisci il carico di lavoro con le istanze del lettore](#ams-waits.respond-to-client.actions.balance)
+ [Utilizzare il modificatore SQL\$1BUFFER\$1RESULT](#ams-waits.respond-to-client.actions.sql-buffer-result)
### Identificare le sessioni e le query che causano gli eventi
È possibile utilizzare Performance Insights per mostrare le query bloccate dall’evento di attesa `io/aurora_respond_to_client`. 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 un'utile panoramica sulla risoluzione dei problemi con Performance Insights, consulta il post sul blog AWS Database [Analyze Amazon Aurora MySQL Workloads](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) with Performance Insights.
### Dimensionamento della classe dell’istanza database
Verifica l'aumento del valore delle CloudWatch metriche di Amazon relative al throughput di rete, ad esempio `NetworkReceiveThroughput` e. `NetworkTransmitThroughput` Se viene raggiunta la larghezza di banda di rete della classe di istanza database, è possibile dimensionare la classe di istanza database utilizzata dal cluster del database modificando il cluster del database. Una classe di istanze database con larghezza di banda di rete maggiore restituisce i dati ai client in modo più efficiente.
Per informazioni sul monitoraggio dei CloudWatch parametri di Amazon, consulta[Visualizzazione delle metriche nella console Amazon RDS](USER_Monitoring.md). Per informazioni sulle classi di istanza database, consulta [Classi di istanze DB Amazon Aurora](Concepts.DBInstanceClass.md). Per informazioni sulla modifica di un cluster di database, consulta [Modifica di un cluster database Amazon Aurora](Aurora.Modifying.md).
### Verifica del carico di lavoro per risultati imprevisti
Controlla il carico di lavoro sul cluster del database e assicurati che non produca risultati imprevisti. Ad esempio, potrebbero esserci query che restituiscono un numero di righe più alto del previsto. In questo caso, puoi utilizzare i parametri del contatore di Performance Insights come `Innodb_rows_read`. Per ulteriori informazioni, consulta [Metriche contatore di Performance Insights](USER_PerfInsights_Counters.md).
### Distribuisci il carico di lavoro con le istanze del lettore
È possibile distribuire il carico di lavoro di sola lettura con le repliche di Aurora. È possibile dimensionare orizzontalmente aggiungendo più repliche di Aurora. Ciò può comportare un aumento dei limiti per la larghezza di banda della rete. Per ulteriori informazioni, consulta [Cluster database Amazon Aurora](Aurora.Overview.md).
### Utilizzare il modificatore SQL\$1BUFFER\$1RESULT
Puoi aggiungere il modificatore `SQL_BUFFER_RESULT` alle istruzioni `SELECT` per forzare il risultato in una tabella temporanea prima che vengano restituite al client. Questo modificatore può aiutare a risolvere i problemi di prestazioni quando i blocchi InnoDB non vengono liberati perché le query sono presenti nello stato di attesa `io/aurora_respond_to_client`. Per ulteriori informazioni, consulta [Istruzione SELECT](https://dev.mysql.com/doc/refman/5.7/en/select.html) nella documentazione di MySQL.
# io/redo\$1log\$1flush
L’evento `io/redo_log_flush` si verifica quando una sessione sta scrivendo dati persistenti nell’archiviazione di Amazon Aurora.
**Topics**
+ [Versioni del motore supportate](#ams-waits.io-redologflush.context.supported)
+ [Contesto](#ams-waits.io-redologflush.context)
+ [Probabili cause di aumento delle attese](#ams-waits.io-redologflush.causes)
+ [Azioni](#ams-waits.io-redologflush.actions)
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 3
## Contesto
L'`io/redo_log_flush`evento riguarda un'operazione di scrittura input/output (I/O) in Aurora MySQL.
**Nota**
In Aurora MySQL versione 2, questo evento di attesa è denominato [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).
## Probabili cause di aumento delle attese
Per la persistenza dei dati, l’esecuzione dei commit richiede una scrittura duratura per un’archiviazione stabile. Se il database esegue troppi commit, c'è un evento di attesa nell' I/O operazione di scrittura, l'evento wait. `io/redo_log_flush`
Per esempi del comportamento di questo evento di attesa, consulta [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
**Topics**
+ [Identificare le sessioni e le query problematiche](#ams-waits.io-redologflush.actions.identify-queries)
+ [Raggruppa le operazioni di scrittura](#ams-waits.io-redologflush.actions.action0)
+ [Disattivazione dell'autocommit](#ams-waits.io-redologflush.actions.action1)
+ [Transazioni di utilizzo](#ams-waits.io-redologflush.action2)
+ [Utilizza i batch](#ams-waits.io-redologflush.action3)
### Identificare le sessioni e le query problematiche
Se l'istanza database sta riscontrando un collo di bottiglia, il primo compito è quello di trovare le sessioni e le query che lo causano. Per un utile post sul blog AWS Database, consulta [Analizza i carichi di lavoro MySQL di Amazon Aurora](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) con Performance Insights.
**Per identificare sessioni e query che causano un collo di bottiglia**
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 l'istanza database.
1. In **Carico del database**, scegli **Dividi per attesa**.
1. Nella parte inferiore della pagina scegli **Prime Instruzioni SQL**.
Le query nella parte superiore dell'elenco causano il carico più alto sul database.
### Raggruppa le operazioni di scrittura
Gli esempi seguenti attivano l’evento di attesa `io/redo_log_flush`. (Autocommit è attivo.)
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
Per ridurre il tempo impiegato in attesa dell’evento di attesa `io/redo_log_flush`, raggruppa logicamente le operazioni di scrittura in una singola esecuzione di commit per ridurre le chiamate persistenti all’archiviazione.
### Disattivazione dell'autocommit
Disattivare l'autocommit prima di apportare modifiche di grandi dimensioni che non si trovano all'interno di una transazione, come illustrato nell'esempio seguente.
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### Transazioni di utilizzo
È possibile utilizzare le transazioni, come illustrato nell'esempio seguente.
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### Utilizza i batch
Si può anche apportare modifiche in batch, come nell'esempio seguente: Tuttavia, l'utilizzo di batch troppo grandi può causare problemi di prestazioni, specialmente nelle repliche di lettura o durante il point-in-time ripristino (PITR).
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
L’evento `io/socket/sql/client_connection` si verifica quando un thread sta per gestire una nuova connessione.
**Topics**
+ [Versioni del motore supportate](#ams-waits.client-connection.context.supported)
+ [Contesto](#ams-waits.client-connection.context)
+ [Probabili cause di aumento delle attese](#ams-waits.client-connection.causes)
+ [Azioni](#ams-waits.client-connection.actions)
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versioni 2 e 3
## Contesto
L'evento `io/socket/sql/client_connection` indica che mysqld è impegnato a creare thread per gestire le nuove connessioni client in arrivo. In questo scenario, l'elaborazione della manutenzione delle nuove richieste di connessione client rallenta mentre le connessioni attendono l'assegnazione del thread. Per ulteriori informazioni, consulta [Server MySQL (mysqld)](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.mysqld).
## Probabili cause di aumento delle attese
Quando questo evento si verifica più del normale, probabilmente indicando un problema di prestazioni, le cause tipiche includono le seguenti:
+ C'è un improvviso aumento delle nuove connessioni utente dall'applicazione alla istanza Amazon RDS.
+ L'istanza database non è in grado di elaborare nuove connessioni perché la rete, la CPU o la memoria sono state limitate.
## Azioni
Se `io/socket/sql/client_connection` domina l'attività del database, non indica necessariamente un problema di prestazioni. In un database che non è inattivo, un evento di attesa è sempre in primo piano. Agisci solo quando le prestazioni diminuiscono. Consigliamo azioni diverse a seconda delle cause dell'evento di attesa.
**Topics**
+ [Identificare le sessioni e le query problematiche](#ams-waits.client-connection.actions.identify-queries)
+ [Seguire le best practice per la gestione delle connessioni](#ams-waits.client-connection.actions.manage-connections)
+ [Dimensiona verso l’alto la tua istanza se le risorse vengono limitate](#ams-waits.client-connection.upgrade)
+ [Controlla i principali host e i migliori utenti](#ams-waits.client-connection.top-hosts)
+ [Interrogare le tabelle performance\$1schema](#ams-waits.client-connection.perf-schema)
+ [Controlla lo stato del thread delle query](#ams-waits.client-connection.thread-states)
+ [Verifica le tue richieste e le query](#ams-waits.client-connection.auditing)
+ [Crea pool delle connessioni al database](#ams-waits.client-connection.pooling)
### Identificare le sessioni e le query problematiche
Se l'istanza database sta riscontrando un collo di bottiglia, il primo compito è quello di trovare le sessioni e le query che lo causano. Per un utile post sul blog, consulta [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/).
**Per identificare sessioni e query che causano un collo di bottiglia**
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 l'istanza database.
1. In **Carico del database**, scegli **Dividi per attesa**.
1. Nella parte inferiore della pagina scegli **Prime Instruzioni SQL**.
Le query nella parte superiore dell'elenco causano il carico più alto sul database.
### Seguire le best practice per la gestione delle connessioni
Per gestire le tue connessioni, considera le seguenti strategie:
+ Utilizza il pooling di connessioni.
È possibile aumentare gradualmente il numero di connessioni secondo necessità. Per ulteriori informazioni, consulta il whitepaper [Manuale dell'amministratore del database di Amazon Aurora MySQL](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf).
+ Usa un nodo lettore per ridistribuire il traffico di sola lettura.
Per ulteriori informazioni, consultare [Repliche di Aurora](Aurora.Replication.md#Aurora.Replication.Replicas) e [Connessioni degli endpoint Amazon Aurora](Aurora.Overview.Endpoints.md).
### Dimensiona verso l’alto la tua istanza se le risorse vengono limitate
Cerca esempi di limitazione nelle seguenti risorse:
+ CPU
Controlla i CloudWatch parametri di Amazon per un utilizzo elevato della CPU.
+ Rete
Verifica la presenza di un aumento del valore delle CloudWatch metriche `network receive throughput` e. `network transmit throughput` Se l’istanza ha raggiunto il limite di larghezza di banda di rete per la classe di istanza, è consigliabile dimensionare verso l’alto l'istanza RDS a un tipo di classe di istanza superiore. Per ulteriori informazioni, consulta [Classi di istanze DB Amazon Aurora](Concepts.DBInstanceClass.md).
+ Memoria liberabile
Verifica la presenza di un calo della CloudWatch metrica`FreeableMemory`. Inoltre, prendi in considerazione l'attivazione del monitoraggio avanzato. Per ulteriori informazioni, consulta [Monitoraggio dei parametri del sistema operativo con il monitoraggio avanzato](USER_Monitoring.OS.md).
### Controlla i principali host e i migliori utenti
Usa Performance Insights per controllare i principali host e i migliori utenti. Per ulteriori informazioni, consulta [Analisi delle metriche utilizzando il pannello di controllo Performance Insights](USER_PerfInsights.UsingDashboard.md).
### Interrogare le tabelle performance\$1schema
Per ottenere un conteggio accurato delle connessioni correnti e totali, eseguire una query sulle tabelle `performance_schema`. Con questa tecnica, si identifica l'utente o l'host di origine responsabile della creazione di un numero elevato di connessioni. Ad esempio, interrogare le tabelle `performance_schema` come indicato di seguito.
```
SELECT * FROM performance_schema.accounts;
SELECT * FROM performance_schema.users;
SELECT * FROM performance_schema.hosts;
```
### Controlla lo stato del thread delle query
Se il problema relativo alle prestazioni è continuo, controlla lo stato del thread delle query. Nel client `mysql`, eseguire il comando seguente.
```
show processlist;
```
### Verifica le tue richieste e le query
Per verificare la natura delle richieste e delle interrogazioni provenienti dagli account utente, usa AuroraAurora MySQL Advanced Auditing. Per informazioni su come attivare l'auditing, consulta [Utilizzo dell'audit avanzato con un cluster di database Amazon Aurora MySQL](AuroraMySQL.Auditing.md).
### Crea pool delle connessioni al database
Valuta l'utilizzo di Amazon RDS Proxy per la gestione della connessione. Con RDS Proxy, è possibile consentire alle applicazioni di creare pool delle connessioni di database e condividerle per migliorare la loro capacità di dimensionamento. RDS Proxy rende le applicazioni più resilienti agli errori del database connettendosi automaticamente a un'istanza database di standby, mantenendo al contempo le connessioni delle applicazioni. Per ulteriori informazioni, consulta [Proxy Amazon RDS per Aurora](rds-proxy.md).
# io/table/sql/handler
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
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versioni 2 e 3
## Contesto
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
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
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
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
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
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.
# synch/cond/innodb/row\$1blocca\$1aspetta
L’evento `synch/cond/innodb/row_lock_wait` si verifica quando una sessione ha bloccato una riga per un aggiornamento e un'altra sessione tenta di aggiornare la stessa riga. Per ulteriori informazioni, consulta l'argomento sul [blocco in InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html) nella documentazione di MySQL.
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 3
## Probabili cause di aumento delle attese
Le diverse istruzioni relative al linguaggio di manipolazione dei dati (DML) accedono contemporaneamente alla stessa riga o righe.
## Azioni
Consigliamo azioni diverse a seconda degli altri eventi di attesa visualizzati.
**Topics**
+ [Trova e rispondi alle istruzioni SQL responsabili di questo evento di attesa](#ams-waits.row-lock-wait.actions.id)
+ [Trova e rispondi alla sessione di blocco](#ams-waits.row-lock-wait.actions.blocker)
### Trova e rispondi alle istruzioni SQL responsabili di questo evento di attesa
Utilizzare Approfondimenti sulle prestazioni per identificare le istruzioni SQL responsabili di questo evento di attesa. Considera le strategie seguenti:
+ Se i blocchi di riga sono un problema persistente, considera la possibilità di riscrivere l'applicazione per utilizzare il blocco ottimistico.
+ Utilizza istruzioni multiriga.
+ Distribuisci il carico di lavoro su diversi oggetti di database. Per farlo, puoi utilizzare il partizionamento.
+ Verifica il valore del parametro `innodb_lock_wait_timeout`. Controlla la durata di attesa delle transazioni prima di generare un errore di timeout.
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/).
### Trova e rispondi alla sessione di blocco
Determina se la sessione di blocco è inattiva o attiva. Inoltre, scopri se la sessione proviene da un'applicazione o da un utente attivo.
Per identificare la sessione che tiene il blocco, è possibile eseguire `SHOW ENGINE INNODB STATUS`. Il seguente esempio mostra un output campione.
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 1688153, ACTIVE 82 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 4244, OS thread handle 70369524330224, query id 4020834 172.31.14.179 reinvent executing
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 24 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 4 n bits 72 index GEN_CLUST_INDEX of table test.t1 trx id 1688153 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
In alternativa, è possibile usare la seguente query per estrarre i dettagli sui blocchi correnti.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_engine_transaction_id waiting_transaction,
ilw.blocking_engine_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_engine_transaction_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state end blocker_state,
concat(il.object_schema,'.', il.object_name) as locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM performance_schema.data_lock_waits ilw
JOIN performance_schema.data_locks il
ON ilw.blocking_engine_lock_id = il.engine_lock_id
AND ilw.blocking_engine_transaction_id = il.engine_transaction_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_engine_transaction_id = it.trx_id join information_schema.processlist p
ON it.trx_mysql_thread_id = p.id join information_schema.innodb_trx it1
ON ilw.requesting_engine_transaction_id = it1.trx_id join information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 4244
waiting_user: reinvent
waiting_host: 123.456.789.012:18158
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 1688153
blocking_lock: 70369562074216:11:4:2:70369549808672
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 1688142
blocker_state: User sleep
locked_table: test.t1
blocker_thread: 4243
blocker_user: reinvent
blocker_host: 123.456.789.012:18156
1 row in set (0.00 sec)
```
Quando si identifica la sessione, le opzioni includono quanto segue:
+ Contattare il proprietario dell'applicazione o l'utente.
+ Se la sessione di blocco è inattiva, considerare di terminare la sessione di blocco. Questa azione potrebbe innescare un lungo ripristino dello stato precedente. Per informazioni su come terminare una sessione, consulta [Terminare una sessione o una query](mysql-stored-proc-ending.md).
Per ulteriori informazioni su come identificare le transazioni di blocco, consulta [Using InnoDB transaction and locking information](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-examples.html) nella documentazione di MySQL.
# synch/cond/innodb/row\$1lock\$1wait\$1cond
L’evento `synch/cond/innodb/row_lock_wait_cond` si verifica quando una sessione ha bloccato una riga per un aggiornamento e un'altra sessione tenta di aggiornare la stessa riga. Per ulteriori informazioni, consulta l'argomento sul [blocco in InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) nella documentazione di MySQL.
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 2
## Probabili cause di aumento delle attese
Le diverse istruzioni relative al linguaggio di manipolazione dei dati (DML) accedono contemporaneamente alla stessa riga o righe.
## Azioni
Consigliamo azioni diverse a seconda degli altri eventi di attesa visualizzati.
**Topics**
+ [Trova e rispondi alle istruzioni SQL responsabili di questo evento di attesa](#ams-waits.row-lock-wait-cond.actions.id)
+ [Trova e rispondi alla sessione di blocco](#ams-waits.row-lock-wait-cond.actions.blocker)
### Trova e rispondi alle istruzioni SQL responsabili di questo evento di attesa
Utilizzare Approfondimenti sulle prestazioni per identificare le istruzioni SQL responsabili di questo evento di attesa. Considera le strategie seguenti:
+ Se i blocchi di riga sono un problema persistente, considera la possibilità di riscrivere l'applicazione per utilizzare il blocco ottimistico.
+ Utilizza istruzioni multiriga.
+ Distribuisci il carico di lavoro su diversi oggetti di database. Per farlo, puoi utilizzare il partizionamento.
+ Verifica il valore del parametro `innodb_lock_wait_timeout`. Controlla la durata di attesa delle transazioni prima di generare un errore di timeout.
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/).
### Trova e rispondi alla sessione di blocco
Determina se la sessione di blocco è inattiva o attiva. Inoltre, scopri se la sessione proviene da un'applicazione o da un utente attivo.
Per identificare la sessione che tiene il blocco, è possibile eseguire `SHOW ENGINE INNODB STATUS`. Il seguente esempio mostra un output campione.
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 2771110, ACTIVE 112 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 24, OS thread handle 70369573642160, query id 13271336 172.31.14.179 reinvent Sending data
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 43 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 3 n bits 0 index GEN_CLUST_INDEX of table test.t1 trx id 2771110 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
In alternativa, è possibile usare la seguente query per estrarre i dettagli sui blocchi correnti.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
Quando si identifica la sessione, le opzioni includono quanto segue:
+ Contattare il proprietario dell'applicazione o l'utente.
+ Se la sessione di blocco è inattiva, considerare di terminare la sessione di blocco. Questa azione potrebbe innescare un lungo ripristino dello stato precedente. Per informazioni su come terminare una sessione, consulta [Terminare una sessione o una query](mysql-stored-proc-ending.md).
Per ulteriori informazioni su come identificare le transazioni di blocco, consulta [Using InnoDB transaction and locking information](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) nella documentazione di MySQL.
# synch/cond/sql/MDL\$1contesto: :COND\$1WAIT\$1STATUS
L’evento `synch/cond/sql/MDL_context::COND_wait_status` si verifica quando ci sono thread in attesa del blocco dei metadati di una tabella.
**Topics**
+ [Versioni del motore supportate](#ams-waits.cond-wait-status.context.supported)
+ [Contesto](#ams-waits.cond-wait-status.context)
+ [Probabili cause di aumento delle attese](#ams-waits.cond-wait-status.causes)
+ [Azioni](#ams-waits.cond-wait-status.actions)
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versioni 2 e 3
## Contesto
L'evento `synch/cond/sql/MDL_context::COND_wait_status` indica che ci sono thread in attesa di un blocco dei metadati di tabella. In alcuni casi, una sessione contiene un blocco di metadati su una tabella e un'altra sessione tenta di ottenere lo stesso blocco sulla stessa tabella. In tal caso, la seconda sessione attende l’evento di attesa `synch/cond/sql/MDL_context::COND_wait_status`.
MySQL utilizza il blocco dei metadati per gestire l'accesso simultaneo agli oggetti del database e garantire la coerenza dei dati. Il blocco dei metadati si applica a tabelle, schemi, eventi pianificati, tablespace e blocchi utente acquisiti con la funzione `get_lock` e i programmi memorizzati. I programmi memorizzati includono procedure, funzioni e attivazioni. Per ulteriori informazioni, consulta [Blocco dei metadati](https://dev.mysql.com/doc/refman/5.7/en/metadata-locking.html) nella documentazione di MySQL.
L'elenco dei processi MySQL mostra questa sessione nello stato `waiting for metadata lock`. In Approfondimenti sulle prestazioni, se `Performance_schema` è acceso, l'evento `synch/cond/sql/MDL_context::COND_wait_status` viene visualizzato.
Il timeout predefinito per una query in attesa di un blocco dei metadati si basa sul valore del parametro `lock_wait_timeout`, che viene impostato in modo predefinito a 31.536.000 secondi (365 giorni).
Per ulteriori dettagli sui diversi blocchi InnoDB e sui tipi di blocchi che possono causare conflitti, consultare [Blocco InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) nella documentazione di MySQL.
## Probabili cause di aumento delle attese
Quando l’evento `synch/cond/sql/MDL_context::COND_wait_status` appare più che normale, possibilmente indicando un problema di prestazioni, le cause tipiche includono le seguenti:
**Transazioni di lunga durata**
Una o più transazioni stanno modificando una grande quantità di dati e mantengono i blocchi sulle tabelle per un tempo molto lungo.
**Transazioni inattive**
Una o più transazioni rimangono aperte per un lungo periodo, senza che venga eseguito il commit o riprimisto a una precedente versione.
**Istruzioni DDL su tabelle grandi**
Una o più istruzioni di definizione dei dati (DDL), ad esempio i comandi `ALTER TABLE`, sono state eseguite su tabelle molto grandi.
**Blocchi espliciti della tabella**
Ci sono blocchi espliciti sulle tabelle che non vengono rilasciate in modo tempestivo. Ad esempio, potrebbe essere eseguita un'applicazione su istruzioni `LOCK TABLE` impropriamente.
## Azioni
Consigliamo diverse azioni a seconda delle cause dell'evento di attesa e della versione del cluster del database di Aurora MySQL.
**Topics**
+ [Identificare le sessioni e le query che causano gli eventi](#ams-waits.cond-wait-status.actions.identify)
+ [Verifica la presenza di eventi passati](#ams-waits.cond-wait-status.actions.past-events)
+ [Esegui query su Aurora MySQL versione 2](#ams-waits.cond-wait-status.actions.run-queries-aurora-mysql-57)
+ [Rispondere alla sessione di blocco](#ams-waits.cond-wait-status.actions.blocker)
### Identificare le sessioni e le query che causano gli eventi
È possibile utilizzare Approfondimenti sulle prestazioni per mostrare le query bloccate dall’evento di attesa `synch/cond/sql/MDL_context::COND_wait_status`. Tuttavia, per identificare la sessione di blocco, eseguire una query sulle tabelle dei metadati da `performance_schema` e `information_schema` sul cluster del database.
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 un'utile panoramica sulla risoluzione dei problemi con Performance Insights, consulta il post sul blog AWS Database [Analyze Amazon Aurora MySQL Workloads](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) with Performance Insights.
### Verifica la presenza di eventi passati
È possibile ottenere informazioni dettagliate su questo evento di attesa per verificare la presenza di occorrenze passate. Per fare ciò, completare questa procedura:
+ Controllare il linguaggio di manipolazione dei dati (DML) e la velocità effettiva e la latenza del DDL per verificare se sono state apportate modifiche al carico di lavoro.
È possibile utilizzare Approfondimenti sulle prestazioni per trovare query in attesa di questo evento al momento del problema. Inoltre, è possibile visualizzare il digest delle query eseguite vicino al momento del problema.
+ Se i registri di verifica o i registri generali sono attivati per il cluster el database, è possibile verificare la presenza di tutte le query eseguite sugli oggetti (schema.table) coinvolti nella transazione in attesa. È inoltre possibile verificare la presenza delle query completate in esecuzione prima della transazione.
Le informazioni disponibili per l’identificazione e la risoluzione dei problemi degli eventi passati sono limitate. L'esecuzione di queste verifiche non mostra quale oggetto è in attesa di informazioni. Tuttavia, è possibile identificare le tabelle con un carico pesante al momento dell'evento e la serie di righe gestite di frequente che causano conflitti al momento del problema. È quindi possibile utilizzare queste informazioni per riprodurre il problema in un ambiente di test e fornire informazioni dettagliate sulla sua causa.
### Esegui query su Aurora MySQL versione 2
In Aurora MySQL versione 2, è possibile identificare direttamente la sessione bloccata eseguendo una query sulle tabelle `performance_schema` o visualizzazione dello schema `sys`. Un esempio può illustrare come interrogare le tabelle per identificare query e sessioni di blocco.
Nel seguente output dell'elenco dei processi, l'ID di connessione `89` è in attesa di un blocco dei metadati e sta eseguendo un comando `TRUNCATE TABLE`. In una query sulle tabelle `performance_schema` o visualizzazioni dello schema `sys`, l'output mostra che la sessione di blocco è `76`.
```
MySQL [(none)]> select @@version, @@aurora_version;
+-----------+------------------+
| @@version | @@aurora_version |
+-----------+------------------+
| 5.7.12 | 2.11.5 |
+-----------+------------------+
1 row in set (0.01 sec)
MySQL [(none)]> show processlist;
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| 2 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 4 | rdsadmin | localhost | NULL | Sleep | 2 | NULL | NULL |
| 5 | rdsadmin | localhost | NULL | Sleep | 1 | NULL | NULL |
| 20 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 21 | rdsadmin | localhost | NULL | Sleep | 261 | NULL | NULL |
| 66 | auroramysql5712 | 172.31.21.51:52154 | sbtest123 | Sleep | 0 | NULL | NULL |
| 67 | auroramysql5712 | 172.31.21.51:52158 | sbtest123 | Sleep | 0 | NULL | NULL |
| 68 | auroramysql5712 | 172.31.21.51:52150 | sbtest123 | Sleep | 0 | NULL | NULL |
| 69 | auroramysql5712 | 172.31.21.51:52162 | sbtest123 | Sleep | 0 | NULL | NULL |
| 70 | auroramysql5712 | 172.31.21.51:52160 | sbtest123 | Sleep | 0 | NULL | NULL |
| 71 | auroramysql5712 | 172.31.21.51:52152 | sbtest123 | Sleep | 0 | NULL | NULL |
| 72 | auroramysql5712 | 172.31.21.51:52156 | sbtest123 | Sleep | 0 | NULL | NULL |
| 73 | auroramysql5712 | 172.31.21.51:52164 | sbtest123 | Sleep | 0 | NULL | NULL |
| 74 | auroramysql5712 | 172.31.21.51:52166 | sbtest123 | Sleep | 0 | NULL | NULL |
| 75 | auroramysql5712 | 172.31.21.51:52168 | sbtest123 | Sleep | 0 | NULL | NULL |
| 76 | auroramysql5712 | 172.31.21.51:52170 | NULL | Query | 0 | starting | show processlist |
| 88 | auroramysql5712 | 172.31.21.51:52194 | NULL | Query | 22 | User sleep | select sleep(10000) |
| 89 | auroramysql5712 | 172.31.21.51:52196 | NULL | Query | 5 | Waiting for table metadata lock | truncate table sbtest.sbtest1 |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
18 rows in set (0.00 sec)
```
Successivamente, una query sulle tabelle `performance_schema` o visualizzazioni dello schema `sys` mostra che la sessione di blocco è `76`.
```
MySQL [(none)]> select * from sys.schema_table_lock_waits;
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| object_schema | object_name | waiting_thread_id | waiting_pid | waiting_account | waiting_lock_type | waiting_lock_duration | waiting_query | waiting_query_secs | waiting_query_rows_affected | waiting_query_rows_examined | blocking_thread_id | blocking_pid | blocking_account | blocking_lock_type | blocking_lock_duration | sql_kill_blocking_query | sql_kill_blocking_connection |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| sbtest | sbtest1 | 121 | 89 | auroramysql5712@192.0.2.0 | EXCLUSIVE | TRANSACTION | truncate table sbtest.sbtest1 | 10 | 0 | 0 | 108 | 76 | auroramysql5712@192.0.2.0 | SHARED_READ | TRANSACTION | KILL QUERY 76 | KILL 76 |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
1 row in set (0.00 sec)
```
### Rispondere alla sessione di blocco
Quando si identifica la sessione, le opzioni includono quanto segue:
+ Contattare il proprietario dell'applicazione o l'utente.
+ Se la sessione di blocco è inattiva, considerare di terminare la sessione di blocco. Questa azione potrebbe innescare un lungo ripristino dello stato precedente. Per informazioni su come terminare una sessione, consulta [Terminare una sessione o una query](mysql-stored-proc-ending.md).
Per ulteriori informazioni su come identificare le transazioni di blocco, consulta [Utilizzo delle informazioni sulle transazioni InnoDB e sul blocco](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) nella documentazione di MySQL.
# synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex
L’evento `synch/mutex/innodb/aurora_lock_thread_slot_futex` si verifica quando una sessione ha bloccato una riga per un aggiornamento e un'altra sessione tenta di aggiornare la stessa riga. Per ulteriori informazioni, consulta [Blocco in InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) nel *Riferimento di MySQL*.
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 2
## Probabili cause di aumento delle attese
Le diverse istruzioni relative al linguaggio di manipolazione dei dati (DML) accedono contemporaneamente alla stessa riga o righe.
## Azioni
Consigliamo azioni diverse a seconda degli altri eventi di attesa visualizzati.
**Topics**
+ [Trova e rispondi alle istruzioni SQL responsabili di questo evento di attesa](#ams-waits.waitsynch.actions.id)
+ [Trova e rispondi alla sessione di blocco](#ams-waits.waitsynch.actions.blocker)
### Trova e rispondi alle istruzioni SQL responsabili di questo evento di attesa
Utilizzare Approfondimenti sulle prestazioni per identificare le istruzioni SQL responsabili di questo evento di attesa. Considera le strategie seguenti:
+ Se i blocchi di riga sono un problema persistente, considera la possibilità di riscrivere l'applicazione per utilizzare il blocco ottimistico.
+ Utilizza istruzioni multiriga.
+ Distribuisci il carico di lavoro su diversi oggetti di database. Per farlo, puoi utilizzare il partizionamento.
+ Verifica il valore del parametro `innodb_lock_wait_timeout`. Controlla la durata di attesa delle transazioni prima di generare un errore di timeout.
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/).
### Trova e rispondi alla sessione di blocco
Determina se la sessione di blocco è inattiva o attiva. Inoltre, scopri se la sessione proviene da un'applicazione o da un utente attivo.
Per identificare la sessione che tiene il blocco, è possibile eseguire `SHOW ENGINE INNODB STATUS`. Il seguente esempio mostra un output campione.
```
mysql> SHOW ENGINE INNODB STATUS;
---------------------TRANSACTION 302631452, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 80109, OS thread handle 0x2ae915060700, query id 938819 10.0.4.12 reinvent updating
UPDATE sbtest1 SET k=k+1 WHERE id=503
------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 148 page no 11 n bits 30 index `PRIMARY` of table `sysbench2`.`sbtest1` trx id 302631452 lock_mode X locks rec but not gap waiting
Record lock, heap no 30 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
```
In alternativa, è possibile usare la seguente query per estrarre i dettagli sui blocchi correnti.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
Quando si identifica la sessione, le opzioni includono quanto segue:
+ Contattare il proprietario dell'applicazione o l'utente.
+ Se la sessione di blocco è inattiva, considerare di terminare la sessione di blocco. Questa azione potrebbe innescare un lungo ripristino dello stato precedente. Per informazioni su come terminare una sessione, consulta [Terminare una sessione o una query](mysql-stored-proc-ending.md).
Per ulteriori informazioni su come identificare le transazioni di blocco, consulta [Utilizzo delle informazioni sulle transazioni InnoDB e sul blocco](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) nel *Manuale di riferimento di MySQL*.
# synch/mutex/innodb/buf\$1pool\$1mutex
L’evento `synch/mutex/innodb/buf_pool_mutex` si verifica quando un thread ha acquisito un blocco nel pool di buffer InnoDB per accedere a una pagina in memoria.
**Topics**
+ [Versioni del motore rilevanti](#ams-waits.bufpoolmutex.context.supported)
+ [Context](#ams-waits.bufpoolmutex.context)
+ [Probabili cause di aumento delle attese](#ams-waits.bufpoolmutex.causes)
+ [Azioni](#ams-waits.bufpoolmutex.actions)
## Versioni del motore rilevanti
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 2
## Context
La mutex `buf_pool` è una mutex singola che protegge le strutture di dati di controllo del pool di buffer.
Per ulteriori informazioni, consulta [Monitoraggio delle attese di Mutex di InnoDB utilizzando lo schema delle prestazioni](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html) nella documentazione di MySQL.
## Probabili cause di aumento delle attese
Si tratta di un evento di attesa specifico per il carico di lavoro. Cause comuni perché `synch/mutex/innodb/buf_pool_mutex` appaia tra i primi eventi di attesa includono quanto segue:
+ Le dimensioni del pool di buffer non sono abbastanza grandi da contenere la serie di dati funzionante.
+ Il carico di lavoro è più specifico per determinate pagine di una tabella specifica del database, causando contese nel pool di buffer.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell'evento di attesa.
**Topics**
+ [Identificare le sessioni e le query che causano gli eventi](#ams-waits.bufpoolmutex.actions.identify)
+ [Utilizzo di Performance Insights](#ams-waits.bufpoolmutex.actions.action1)
+ [Crea repliche di Aurora](#ams-waits.bufpoolmutex.actions.action2)
+ [Analisi delle dimensioni del pool di buffer](#ams-waits.bufpoolmutex.actions.action3)
+ [Monitoraggio della cronologia di stato globale](#ams-waits.bufpoolmutex.actions.action4)
### Identificare le sessioni e le query che causano gli eventi
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 visualizzare il grafico SQL principale nella Console di gestione AWS**
1. 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 **Performance Insights**.
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. Sotto il grafico **Carico del database**, seleziona **Prime istruzioni 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[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/).
### Utilizzo di Performance Insights
Questo evento è correlato al carico di lavoro. È possibile utilizzare Performance Insights per effettuare quanto segue:
+ Identificare l'avvio degli eventi di attesa e se c'è qualche modifica nel carico di lavoro in quel periodo dai registri dell'applicazione o dalle origini correlate.
+ Identificare le istruzioni SQL responsabili di questo evento di attesa. Esaminare il piano di esecuzione delle query per accertarsi che queste query siano ottimizzate e utilizzino indici appropriati.
Se le query principali responsabili dell'evento di attesa sono correlate allo stesso oggetto o tabella di database, prendere in considerazione il partizionamento dell'oggetto o della tabella.
### Crea repliche di Aurora
È possibile creare repliche di Aurora per gestire il traffico di sola lettura. È inoltre possibile utilizzare Auto Scaling di Aurora per gestire le sovratensioni nel traffico di lettura. Assicurarsi di eseguire attività di sola lettura pianificate e backup logici sulle repliche di Aurora.
Per ulteriori informazioni, consulta [Dimensionamento automatico di Amazon Aurora con le repliche Aurora](Aurora.Integrating.AutoScaling.md).
### Analisi delle dimensioni del pool di buffer
Verificare se la dimensione del pool di buffer è sufficiente per il carico di lavoro esaminando il parametro `innodb_buffer_pool_wait_free`. Se il valore di questo parametro è alto e aumenta continuamente, ciò indica che la dimensione del pool di buffer non è sufficiente per gestire il carico di lavoro. Se `innodb_buffer_pool_size` è stato impostato correttamente, il valore di `innodb_buffer_pool_wait_free`dovrebbe essere piccolo. Per ulteriori informazioni, consulta [Innodb\$1buffer\$1pool\$1wait\$1free](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Innodb_buffer_pool_wait_free) nella documentazione di MySQL.
Aumentare le dimensioni del pool di buffer se l'istanza database dispone di memoria sufficiente per i buffer di sessione e le attività del sistema operativo. In caso contrario, modificare l'istanza database in una classe di istanza database più grande per ottenere memoria aggiuntiva che può essere allocata al pool di buffer.
**Nota**
Aurora MySQL regola automaticamente il valore di `innodb_buffer_pool_instances` basato sul configurato `innodb_buffer_pool_size`.
### Monitoraggio della cronologia di stato globale
Monitorando i tassi di modifica delle variabili di stato, è possibile rilevare problemi di blocco o di memoria sull'istanza database. Attivare Global Status History (GoSH) se non è già attivo. Per ulteriori informazioni su GoSH, consulta [Gestione della cronologia di stato globale](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH).
Puoi anche creare parametri personalizzati di Amazon CloudWatch per monitorare le variabili di stato. Per ulteriori informazioni, consulta [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html).
# synch/mutex/innodb/fil\$1sistema\$1mutex
L’evento `synch/mutex/innodb/fil_system_mutex` si verifica quando una sessione è in attesa di accedere alla cache di memoria tablespace.
**Topics**
+ [Versioni del motore supportate](#ams-waits.innodb-fil-system-mutex.context.supported)
+ [Contesto](#ams-waits.innodb-fil-system-mutex.context)
+ [Probabili cause di aumento delle attese](#ams-waits.innodb-fil-system-mutex.causes)
+ [Azioni](#ams-waits.innodb-fil-system-mutex.actions)
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versioni 2 e 3
## Contesto
InnoDB utilizza tablespace per gestire l'area di archiviazione per tabelle e file di registro. La *cache di memoria di tablespace* è una struttura di memoria globale che mantiene le informazioni sulle tablespace. MySQL utilizza attese `synch/mutex/innodb/fil_system_mutex` per controllare l'accesso simultaneo alla cache di memoria di tablespace.
L'evento `synch/mutex/innodb/fil_system_mutex` indica che attualmente esistono più operazioni che devono recuperare e manipolare le informazioni nella cache di memoria di tablespace per la stessa tablespace.
## Probabili cause di aumento delle attese
Quando l’evento `synch/mutex/innodb/fil_system_mutex` appare più che normale, possibilmente indicando un problema di prestazioni, generalmente accade quando sono presenti tutte le seguenti condizioni:
+ Un aumento simultaneo delle operazioni relative al linguaggio di manipolazione dei dati (DM) che che aggiornano o eliminano i dati nella stessa tabella.
+ La tablespace per questa tabella è molto ampia e ha molte pagine di dati.
+ Il fattore di riempimento per queste pagine di dati è basso.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
**Topics**
+ [Identificare le sessioni e le query che causano gli eventi](#ams-waits.innodb-fil-system-mutex.actions.identify)
+ [Riorganizza tabelle di grandi dimensioni durante le ore non di picco](#ams-waits.innodb-fil-system-mutex.actions.reorganize)
### Identificare le sessioni e le query che causano gli eventi
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 Performance Insights 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[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/).
Un altro modo per scoprire quali query causano un numero elevato di attese `synch/mutex/innodb/fil_system_mutex` è di controllare `performance_schema`, come nel seguente esempio.
```
mysql> select * from performance_schema.events_waits_current where EVENT_NAME='wait/synch/mutex/innodb/fil_system_mutex'\G
*************************** 1. row ***************************
THREAD_ID: 19
EVENT_ID: 195057
END_EVENT_ID: 195057
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:6700
TIMER_START: 1010146190118400
TIMER_END: 1010146196524000
TIMER_WAIT: 6405600
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 2. row ***************************
THREAD_ID: 23
EVENT_ID: 5480
END_EVENT_ID: 5480
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:5906
TIMER_START: 995269979908800
TIMER_END: 995269980159200
TIMER_WAIT: 250400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 3. row ***************************
THREAD_ID: 55
EVENT_ID: 23233794
END_EVENT_ID: NULL
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:449
TIMER_START: 1010492125341600
TIMER_END: 1010494304900000
TIMER_WAIT: 2179558400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: 23233786
NESTING_EVENT_TYPE: WAIT
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
```
### Riorganizza tabelle di grandi dimensioni durante le ore non di picco
Riorganizza tabelle di grandi dimensioni che identifichi come fonte di un numero elevato di eventi di attesa `synch/mutex/innodb/fil_system_mutex` durante una finestra temporale di manutenzione al di fuori dell'orario di produzione. In questo modo si assicura che la pulizia della mappa delle tablespace interne non si verifichi quando l'accesso rapido alla tabella è fondamentale. Per informazioni sulla riorganizzazione delle tabelle, consulta [Istruzione OPTIMIZE TABLE](https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html) nel *Riferimento di MySQL*.
# synch/mutex/innodb/trx\$1sys\$1mutex
L’evento `synch/mutex/innodb/trx_sys_mutex` si verifica quando c'è un'elevata attività del database con un numero elevato di transazioni.
**Topics**
+ [Versioni del motore rilevanti](#ams-waits.trxsysmutex.context.supported)
+ [Context](#ams-waits.trxsysmutex.context)
+ [Probabili cause di aumento delle attese](#ams-waits.trxsysmutex.causes)
+ [Azioni](#ams-waits.trxsysmutex.actions)
## Versioni del motore rilevanti
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versioni 2 e 3
## Context
Internamente, il motore di database InnoDB utilizza il livello di isolamento della lettura ripetibile con snapshot per fornire coerenza di lettura. In questo modo viene consentita una visualizzazione istantanea del database al momento della creazione dello snapshot.
In InnoDB, tutte le modifiche vengono applicate al database non appena arrivano, indipendentemente dal fatto che sia stato eseguito il commit. Questo approccio significa che senza il controllo della concorrenza multiversione (MVCC), tutti gli utenti connessi al database vedono tutte le modifiche e le righe più recenti. Pertanto, InnoDB richiede un modo per tenere traccia delle modifiche per capire cosa ripristinare allo stato precedente quando necessario.
Per fare ciò, InnoDB utilizza un sistema di transazioni (`trx_sys`) per tenere traccia degli snapshot. Il sistema di transazioni effettua quanto segue:
+ Tiene traccia dell'ID della transazione per ogni riga nei registri di annullamento.
+ Utilizza una struttura interna InnoDB chiamata `ReadView` che aiuta a identificare quali ID di transazione sono visibili per uno snapshot.
## Probabili cause di aumento delle attese
Qualsiasi operazione di database che richiede la gestione coerente e controllata (creazione, lettura, aggiornamento ed eliminazione) degli ID delle transazioni genera una chiamata da `trx_sys` al mutex.
Queste chiamate avvengono all'interno di tre funzioni:
+ `trx_sys_mutex_enter` – Crea il mutex.
+ `trx_sys_mutex_exit` – Rilascia il mutex.
+ `trx_sys_mutex_own` – Verifica se il mutex è di proprietà.
La strumentazione InnoDB Performance Schema tiene traccia di tutte le chiamate mutex `trx_sys`. Il monitoraggio include, a titolo esemplificativo ma non esaustivo, la gestione di `trx_sys` all'avvio o allo spegnimento del database, operazioni di ripristino dello stato precedente, pulizia degli annullamenti, accesso in lettura di righe e carichi del pool di buffer. L'elevata attività del database con un numero elevato di transazioni comporta la comparsa di `synch/mutex/innodb/trx_sys_mutex` tra i principali eventi di attesa.
Per ulteriori informazioni, consulta [Monitoraggio delle attese di Mutex di InnoDB utilizzando lo schema delle prestazioni](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html) nella documentazione di MySQL.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell'evento di attesa.
**Topics**
+ [Identificare le sessioni e le query che causano gli eventi](#ams-waits.trxsysmutex.actions.identify)
+ [Esamina altri eventi di attesa](#ams-waits.trxsysmutex.actions.action1)
### Identificare le sessioni e le query che causano gli eventi
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. Guarda gli eventi di attesa che contribuiscono al carico più elevato. Scopri se è possibile ottimizzare il database e l'applicazione per ridurre tali eventi.
**Per visualizzare il grafico Istruzioni SQL principali nella Console di gestione AWS**
1. 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 **Performance Insights**.
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. Nel grafico **Carico del database**, seleziona **Prime istruzioni 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[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/).
### Esamina altri eventi di attesa
Esamina gli altri eventi di attesa associati all’evento di attesa `synch/mutex/innodb/trx_sys_mutex`. In questo modo, si possono acquisire ulteriori informazioni sulla natura del carico di lavoro. Un numero elevato di transazioni potrebbe ridurre la velocità effettiva, ma anche il carico di lavoro potrebbe renderlo necessario.
Per ulteriori informazioni su come ottimizzare le transazioni, consulta [Ottimizzazione della gestione delle transazioni InnoDB](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html) nella documentazione di MySQL.
# synch/sxlock/innodb/hash\$1table\$1locks
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
Queste informazioni sull’evento di attesa sono supportate per le seguenti versioni:
+ Aurora MySQL versioni 2 e 3
## Contesto
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
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
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
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
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
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
È 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.
# synch/mutex/innodb/temp\$1pool\$1manager\$1mutex
L'evento `synch/mutex/innodb/temp_pool_manager_mutex` wait si verifica quando una sessione è in attesa di acquisire un mutex per la gestione del pool di tablespace temporanee della sessione.
**Topics**
+ [Versioni del motore supportate](#ams-waits.io-temppoolmanager.context.supported)
+ [Contesto](#ams-waits.io-temppoolmanager.context)
+ [Probabili cause di aumento delle attese](#ams-waits.io-temppoolmanager.causes)
+ [Azioni](#ams-waits.io-temppoolmanager.actions)
## Versioni del motore supportate
Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 3
## Contesto
Aurora MySQL versione 3.x e successive consente di controllare più sessioni che accedono `temp_pool_manager_mutex` al pool di tablespace temporaneo contemporaneamente. Aurora MySQL gestisce l'archiviazione tramite un volume cluster Aurora per i dati persistenti e l'archiviazione locale per i file temporanei. Un tablespace temporaneo è necessario quando una sessione crea una tabella temporanea sul volume del cluster Aurora.
Quando una sessione richiede per la prima volta un tablespace temporaneo, MySQL alloca tablespace temporanei della sessione dal pool condiviso. Una sessione può contenere fino a 2 tablespace temporanee alla volta per i seguenti tipi di tabelle:
+ Tabelle temporanee create dall'utente
+ Tabelle temporanee interne generate dall'ottimizzatore
Il `TempTable` motore predefinito utilizza il seguente meccanismo di overflow per gestire le tabelle temporanee:
+ Memorizza le tabelle nella RAM fino al [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)limite.
+ Passa ai file mappati in memoria nella memoria locale quando la RAM è piena.
+ Utilizza il volume condiviso del cluster quando i file mappati in memoria raggiungono il 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)
Dopo che le tabelle temporanee superano i limiti di RAM e di archiviazione locale, MySQL le gestisce utilizzando tablespace su disco.
Quando una sessione richiede una tabella temporanea su disco, MySQL:
+ Cerca i `INACTIVE` tablespace disponibili nel pool da riutilizzare.
+ Crea 10 nuove tablespace se non esistono spazi. `INACTIVE`
Quando una sessione si disconnette, MySQL:
+ Tronca i tablespace temporanei della sessione.
+ Le contrassegna come INATTIVE nel pool per il riutilizzo.
+ Mantiene la dimensione attuale del pool fino al riavvio del server.
+ Ritorna alla dimensione predefinita del pool (10 tablespace) dopo il riavvio.
## Probabili cause di aumento delle attese
Situazioni comuni che causano questo evento di attesa:
+ Sessioni simultanee che creano tabelle temporanee interne sul volume del cluster.
+ Sessioni simultanee che creano tabelle temporanee utente sul volume del cluster.
+ Interruzione improvvisa delle sessioni utilizzando tablespace attivi.
+ Espansione del pool di tablespace durante carichi di lavoro di scrittura pesanti.
+ Accesso simultaneo alle interrogazioni `INFORMATION_SCHEMA.`
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
**Topics**
+ [Monitora e ottimizza l'utilizzo temporaneo delle tabelle](#ams-waits.io-temppoolmanager.actions.monitor)
+ [Esamina le query utilizzando INFORMATION\$1SCHEMA](#ams-waits.io-temppoolmanager.actions.schema-queries)
+ [Aumenta il parametro innodb\$1sync\$1array\$1size](#ams-waits.io-temppoolmanager.actions.sync_array)
+ [Implementa un pool di connessioni](#ams-waits.io-temppoolmanager.actions.connection_pooling)
### Monitora e ottimizza l'utilizzo temporaneo delle tabelle
Per monitorare e ottimizzare l'utilizzo delle tabelle temporanee, utilizzate uno di questi metodi:
+ Controlla il `Created_tmp_disk_tables` contatore in Performance Insights per tenere traccia della creazione di tabelle temporanee su disco nel cluster Aurora.
+ Esegui questo comando nel tuo database per monitorare direttamente la creazione di tabelle temporanee:. `mysql> show status like '%created_tmp_disk%'`
**Nota**
Il comportamento delle tabelle temporanee differisce tra i nodi reader MySQL di Aurora e i nodi writer. Per ulteriori informazioni, consulta [Nuovo comportamento della tabella temporanea in Aurora MySQL versione 3](ams3-temptable-behavior.md).
Dopo aver identificato le query che creano tabelle temporanee, esegui questi passaggi di ottimizzazione:
+ `EXPLAIN`Utilizzatelo per esaminare i piani di esecuzione delle query e identificare dove e perché vengono create le tabelle temporanee.
+ Modifica le query per ridurre l'utilizzo temporaneo delle tabelle, ove possibile.
Se l'ottimizzazione delle query da sola non risolve i problemi di prestazioni, valuta la possibilità di modificare questi parametri di configurazione:
+ [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)- Controlla l'utilizzo massimo della RAM per le tabelle temporanee.
+ [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)- Imposta il limite per l'archiviazione di file mappati in memoria.
+ [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)- Si applica quando `aurora_tmptable_enable_per_table_limit` è abilitato (disabilitato per impostazione predefinita).
**Importante**
Tieni presente che alcune condizioni di interrogazione richiederanno sempre tabelle temporanee su disco, indipendentemente dalle impostazioni di configurazione. Per ulteriori informazioni sul motore `TempTable` di storage, consulta [Utilizzare il motore TempTable di storage su Amazon RDS for MySQL e Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).
### Esamina le query utilizzando INFORMATION\$1SCHEMA
Quando si interrogano `INFORMATION_SCHEMA` le tabelle, MySQL crea tabelle temporanee InnoDB sul volume del cluster. Ogni sessione necessita di un tablespace temporaneo per queste tabelle, il che può portare a problemi di prestazioni in caso di accesso simultaneo elevato.
Per migliorare le prestazioni:
+ Usalo `PERFORMANCE_SCHEMA` al posto di `INFORMATION_SCHEMA` dove possibile.
+ Se necessario`INFORMATION_SCHEMA`, riduci la frequenza con cui esegui queste query.
### Aumenta il parametro innodb\$1sync\$1array\$1size
Il `innodb_sync_array_size` parametro controlla la dimensione dell'array di mutex/lock attesa in MySQL. Il valore predefinito di `1` funziona per carichi di lavoro generici, ma aumentandolo si può ridurre il conflitto di thread in caso di elevata concorrenza.
Quando il carico di lavoro mostra un numero crescente di thread in attesa:
+ Monitora il numero di thread in attesa nel tuo carico di lavoro.
+ Imposta un numero `innodb_sync_array_size` pari o superiore al numero di vCPU dell'istanza per suddividere la struttura di coordinamento dei thread e ridurre i conflitti.
**Nota**
Per determinare il numero di v CPUs disponibili sulla tua istanza RDS, consulta le specifiche vCPU nei tipi di istanze [Amazon RDS](https://aws.amazon.com/rds/instance-types/).
### Implementa un pool di connessioni
MySQL assegna un tablespace dedicato a ogni sessione che crea una tabella temporanea. Questo tablespace rimane attivo fino al termine della connessione al database. Per gestire le risorse in modo più efficiente:
+ Implementa il pool di connessioni per limitare il numero di tablespace temporanee attive.
+ Riutilizza le connessioni esistenti invece di crearne di nuove per ogni operazione.
# Regolazione di Aurora MySQL con stati del thread
La tabella seguente riassume gli stati del thread generali più comuni per Aurora MySQL.
| Stato del thread generale | Descrizione |
| --- | --- |
| [creazione di indice di ordinamento](ams-states.sort-index.md) | Questo stato del thread indica che un thread sta elaborando un'istruzione `SELECT` che richiede l'uso di una tabella temporanea interna per ordinare i dati. |
| [invio dei dati](ams-states.sending-data.md) | Questo stato del thread indica che un thread sta leggendo e filtrando le righe per cercare una query per determinare la serie di risultati corretti. |
# creazione di indice di ordinamento
Lo stato del thread `creating sort index` indica che un thread sta elaborando un’istruzione `SELECT` che richiede l'uso di una tabella temporanea interna per ordinare i dati.
**Topics**
+ [Versioni del motore supportate](#ams-states.sort-index.context.supported)
+ [Contesto](#ams-states.sort-index.context)
+ [Probabili cause di aumento delle attese](#ams-states.sort-index.causes)
+ [Azioni](#ams-states.sort-index.actions)
## Versioni del motore supportate
Queste informazioni sullo stato del thread sono supportate per le seguenti versioni:
+ Aurora MySQL versione 2 fino alla 2.09.2
## Contesto
Lo stato `creating sort index` appare quando una query con una clausola `ORDER BY` o `GROUP BY` non può utilizzare un indice esistente per eseguire l'operazione. In questo caso, MySQL deve eseguire un’operazione `filesort` più costosa. Questa operazione viene generalmente eseguita in memoria se la serie di risultati non è troppo grande. In caso contrario, comporta la creazione di un file su disco.
## Probabili cause di aumento delle attese
La comparsa di `creating sort index` non indica di per sé un problema. Se le prestazioni sono scadenti e si vedono frequenti istanze di `creating sort index`, la causa più probabile è query lente con operatori `ORDER BY` o `GROUP BY`.
## Azioni
La linea guida generale è trovare query con clausole `ORDER BY` o `GROUP BY` associate agli aumenti dello stato `creating sort index`. Quindi verificare se l'aggiunta di un indice o l'aumento della dimensione del buffer di ordinamento risolve il problema.
**Topics**
+ [Attiva il Performance Schema se non è attivato](#ams-states.sort-index.actions.enable-pfs)
+ [Identificare le query problematiche](#ams-states.sort-index.actions.identify)
+ [Esaminare i piani di spiegazione per l'utilizzo di filesort](#ams-states.sort-index.actions.plan)
+ [Aumenta la dimensione del buffer di ordinamento](#ams-states.sort-index.actions.increasebuffersize)
### Attiva il Performance Schema se non è attivato
Performance Insights segnala gli stati del thread solo se gli strumenti di Performance Schema non sono attivati. Quando gli strumenti di Performance Schema sono attivati, Performance Insights segnala invece gli eventi di attesa. Gli strumenti di Performance Schema forniscono informazioni dettagliate aggiuntive e strumenti migliori quando si esaminano potenziali problemi di prestazione. Pertanto, è consigliabile attivare il Performance Schema. Per ulteriori informazioni, consulta [Panoramica dello schema di prestazioni per Approfondimenti sulle prestazioni su Aurora MySQL](USER_PerfInsights.EnableMySQL.md).
### Identificare le query problematiche
Per identificare le query correnti che causano un aumento dello stato `creating sort index`, eseguire `show processlist` e vedi se una qualsiasi delle query ha `ORDER BY` o `GROUP BY`. Facoltativamente, eseguire `explain for connection N`, dove `N` è l'ID dell'elenco dei processi della query con `filesort`.
Per identificare le query precedenti che causano questi aumenti, attiva il registro delle query lente e trova le query con `ORDER BY`. Esegui `EXPLAIN` sulle query lente e cerca “utilizzo di filesort”. Per ulteriori informazioni, consulta [Esaminare i piani di spiegazione per l'utilizzo di filesort](#ams-states.sort-index.actions.plan).
### Esaminare i piani di spiegazione per l'utilizzo di filesort
Identifica le istruzioni con clausole `ORDER BY` o `GROUP BY` che si traducono nello stato `creating sort index`.
Negli esempi seguenti viene illustrato come eseguire `explain` su una query. La colonna `Extra` mostra che questa query utilizza `filesort`.
```
mysql> explain select * from mytable order by c1 limit 10\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: mytable
partitions: NULL
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 2064548
filtered: 100.00
Extra: Using filesort
1 row in set, 1 warning (0.01 sec)
```
L'esempio seguente mostra il risultato dell'esecuzione di `EXPLAIN` sulla stessa query dopo la creazione di un indice sulla colonna `c1`.
```
mysql> alter table mytable add index (c1);
```
```
mysql> explain select * from mytable order by c1 limit 10\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: mytable
partitions: NULL
type: index
possible_keys: NULL
key: c1
key_len: 1023
ref: NULL
rows: 10
filtered: 100.00
Extra: Using index
1 row in set, 1 warning (0.01 sec)
```
Per informazioni sull'utilizzo degli indici per l'ottimizzazione dell'ordinamento, consulta [Ottimizzazione ORDER BY](https://dev.mysql.com/doc/refman/5.7/en/order-by-optimization.html) nella documentazione di MySQL.
### Aumenta la dimensione del buffer di ordinamento
Per verificare se una query specifica richiedeva un processo `filesort` che ha creato un file su disco, controllare il valore della variabile `sort_merge_passes` dopo aver eseguito la query. Di seguito viene riportato un esempio.
```
mysql> show session status like 'sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.01 sec)
--- run query
mysql> select * from mytable order by u limit 10;
--- run status again:
mysql> show session status like 'sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.01 sec)
```
Se il valore di `sort_merge_passes` è alto, si consideri di aumentare la dimensione del buffer di ordinamento. Applica l'aumento a livello di sessione, perché l’aumento a livello globale può aumentare significativamente la quantità di RAM utilizzata da MySQL. L'esempio seguente mostra come modificare le dimensioni del buffer di ordinamento prima di eseguire una query.
```
mysql> set session sort_buffer_size=10*1024*1024;
Query OK, 0 rows affected (0.00 sec)
-- run query
```
# invio dei dati
Lo stato del thread `sending data` indica che un thread sta leggendo e filtrando le righe per una query per determinare la serie di risultati corretti. Il nome è fuorviante perché implica che lo stato sta trasferendo i dati, non raccogliendo e preparando i dati da inviare in seguito.
**Topics**
+ [Versioni del motore supportate](#ams-states.sending-data.context.supported)
+ [Contesto](#ams-states.sending-data.context)
+ [Probabili cause di aumento delle attese](#ams-states.sending-data.causes)
+ [Azioni](#ams-states.sending-data.actions)
## Versioni del motore supportate
Queste informazioni sullo stato del thread sono supportate per le seguenti versioni:
+ Aurora MySQL versione 2 fino alla 2.09.2
## Contesto
Molti stati del thread sono di breve durata. Operazioni che si verificano durante `sending data` tendono a eseguire un numero elevato di letture su disco o cache. Pertanto, `sending data` è spesso lo stato di esecuzione più lungo per tutta la durata di una determinata query. Questo stato viene visualizzato quando Aurora MySQL sta effettuando le seguenti operazioni:
+ Lettura ed elaborazione di righe per un’istruzione `SELECT`
+ Esecuzione di un numero elevato di letture da disco o memoria
+ Completamento di una lettura completa di tutti i dati da una query specifica
+ Lettura di dati da una tabella, da un indice o dal lavoro di una procedura archiviata
+ Ordinamento, raggruppamento o ordinamento dei dati
Dopo che lo stato `sending data` termina la preparazione dei dati, lo stato del thread `writing to net` indica il ritorno dei dati al client. Tipicamente `writing to net` viene acquisito solo quando la serie di risultati è molto grande o una latenza di rete grave rallenta il trasferimento.
## Probabili cause di aumento delle attese
La comparsa di `sending data` non indica di per sé un problema. Se le prestazioni sono scadenti e si vedono frequenti istanze di `sending data`, le cause più probabili sono le seguenti.
**Topics**
+ [Query inefficiente](#ams-states.sending-data.causes.structure)
+ [Configurazione del server non ottimale](#ams-states.sending-data.causes.server)
### Query inefficiente
Nella maggior parte dei casi, ciò che è responsabile di questo stato è una query che non utilizza un indice appropriato per trovare la serie di risultati di una query specifica. Ad esempio, si consideri una query che legge una tabella di dati di 10 milioni per tutti gli ordini effettuati in California, in cui la colonna di stato non è indicizzata o è scarsamente indicizzata. In quest'ultimo caso, l'indice potrebbe esistere, ma l'ottimizzatore lo ignora a causa della bassa cardinalità.
### Configurazione del server non ottimale
Se vengono visualizzate diverse query nello stato `sending data`, il server di database potrebbe essere configurato in modo errato. In particolare, il server potrebbe presentare i seguenti problemi:
+ Il server del database non dispone di una capacità di elaborazione sufficiente: I/O del disco, tipo e velocità del disco, CPU o numero di CPUs.
+ Il server è a corto di risorse allocate, come il pool di buffer InnoDB per le tabelle InnoDB o il buffer di chiavi per le tabelle. MyIsam
+ Impostazioni di memoria per thread come `sort_buffer`, `read_buffer` e`join_buffer` consumano più RAM di quanto richiesto, portando il server fisico a necessitare risorse di memoria.
## Azioni
La linea guida generale consiste nel trovare query che restituiscono un numero elevato di righe controllando il Performance Schema. Se la registrazione di query che non utilizzano indici è attivata, è anche possibile esaminare i risultati dei registri lenti.
**Topics**
+ [Attiva il Performance Schema se non è attivato](#ams-states.sending-data.actions.enable-pfs)
+ [Analisi delle impostazioni della memoria](#ams-states.sending-data.actions.memory)
+ [Esaminare i piani di spiegazione per l'utilizzo dell'indice](#ams-states.sending-data.actions.plans)
+ [Controllare il volume di dati restituiti](#ams-states.sending-data.actions.maintenance)
+ [Verifica la presenza di problemi di concorrenza](#ams-states.sending-data.actions.concurrent-queries)
+ [Verificare la struttura delle query](#ams-states.sending-data.actions.subqueries)
### Attiva il Performance Schema se non è attivato
Performance Insights segnala gli stati del thread solo se gli strumenti di Performance Schema non sono attivati. Quando gli strumenti di Performance Schema sono attivati, Performance Insights segnala invece gli eventi di attesa. Gli strumenti di Performance Schema forniscono informazioni dettagliate aggiuntive e strumenti migliori quando si esaminano potenziali problemi di prestazione. Pertanto, è consigliabile attivare il Performance Schema. Per ulteriori informazioni, consulta [Panoramica dello schema di prestazioni per Approfondimenti sulle prestazioni su Aurora MySQL](USER_PerfInsights.EnableMySQL.md).
### Analisi delle impostazioni della memoria
Esaminare le impostazioni di memoria per i pool di buffer primari. Assicurarsi che questi pool siano ridimensionati in modo appropriato per il carico di lavoro. Se il database utilizza più istanze del pool di buffer, assicurati che non siano divisi in molti piccoli pool di buffer. I thread possono utilizzare solo un pool di buffer alla volta.
Assicurarsi che le seguenti impostazioni di memoria utilizzate per ciascun thread siano dimensionate correttamente:
+ read\$1buffer
+ read\$1rnd\$1buffer
+ sort\$1buffer
+ join\$1buffer
+ binlog\$1cache
A meno che non si abbiano ragioni specifiche per modificare le impostazioni, utilizzare i valori predefiniti.
### Esaminare i piani di spiegazione per l'utilizzo dell'indice
Per queri nello stato del thread `sending data`, esaminare il piano per determinare se vengono utilizzati indici appropriati. Se una query non utilizza un indice utile, si prenda in considerazione l'aggiunta di suggerimenti come `USE INDEX` o `FORCE INDEX`. I suggerimenti possono aumentare o diminuire notevolmente il tempo necessario per eseguire una query, quindi occorre prestare attenzione prima di aggiungerli.
### Controllare il volume di dati restituiti
Controllare le tabelle sottoposte a query e la quantità di dati che contengono. È possibile archiviare qualcuno di questi dati? In molti casi, la causa di tempi di esecuzione delle query scadenti non è il risultato del piano della query, ma il volume di dati da elaborare. Molti sviluppatori sono molto efficienti nell'aggiungere dati a un database, ma raramente considerano il ciclo di vita del set di dati nelle fasi di progettazione e sviluppo.
Si consiglia di cercare query che funzionino bene nei database con volumi ridotti ma che funzionino male nel sistema attuale. A volte gli sviluppatori che progettano query specifiche potrebbero non rendersi conto che queste query restituiscono 350.000 righe. Gli sviluppatori potrebbero aver sviluppato le query in un ambiente con volumi inferiori con set di dati più piccoli rispetto agli ambienti di produzione.
### Verifica la presenza di problemi di concorrenza
Verifica se sono in esecuzione contemporaneamente più query dello stesso tipo. Alcune forme di query vengono eseguite in modo efficiente quando vengono eseguite da sole. Tuttavia, se forme di query simili vengono eseguite insieme o in volume elevato, possono causare problemi di concorrenza. Spesso questi problemi sono causati quando il database utilizza tabelle temporanee per restituire dei risultati. Un livello di isolamento restrittivo delle transazioni può anche causare problemi di concorrenza.
Se le tabelle vengono lette e scritte contemporaneamente, il database potrebbe utilizzare i blocchi. Per aiutare a identificare i periodi di prestazioni scadenti, esaminare l'uso dei database attraverso processi batch su larga scala. Per visualizzare i blocchi e i ripristini degli stati precedenti recenti, esaminare l'output del comando `SHOW ENGINE INNODB STATUS`.
### Verificare la struttura delle query
Verifica se le query acquisite da questi stati utilizzano sottoquery. Questo tipo di query spesso porta a prestazioni scadenti perché il database compila i risultati internamente e li sostituisce nuovamente nella query per la restituzione dei dati. Questo processo è un passaggio aggiuntivo per il database. In molti casi, questo passaggio può causare prestazioni scadenti in condizioni di caricamento altamente concomitante.
Controlla anche se le tue query utilizzano un numero elevato di clausole `ORDER BY` e `GROUP BY`. In tali operazioni, spesso il database deve prima formare l'intero set di dati in memoria. Quindi deve ordinarlo o raggrupparlo in modo specifico prima di restituirlo al client.
# Ottimizzazione di Aurora MySQL con approfondimenti proattivi di Amazon DevOps Guru
Gli approfondimenti proattivi di DevOps Guru rilevano le condizioni problematiche note nel cluster di database Aurora MySQL prima che si verifichino. Con DevOps Guru è possibile:
+ Evitare molti problemi comuni relativi al database controllando la configurazione del database rispetto alle impostazioni consigliate comuni.
+ Ricevere gli avvisi per le criticità relative al parco istanze che, se non controllate, possono portare a problemi più gravi in seguito.
+ Ricevere gli avvisi per i nuovi problemi individuati.
Ogni approfondimento proattivo contiene un'analisi della causa del problema e i suggerimenti per le azioni correttive.
**Topics**
+ [La lunghezza dell'elenco della cronologia di InnoDB è aumentata in modo significativo](proactive-insights.history-list.md)
+ [Il database sta creando tabelle temporanee su disco](proactive-insights.temp-tables.md)
# La lunghezza dell'elenco della cronologia di InnoDB è aumentata in modo significativo
A partire da *date* allora, l'elenco della cronologia delle modifiche alle righe è aumentato in modo significativo, fino a un *length* certo punto*db-instance*. Questo aumento influisce sulle prestazioni di chiusura delle query e arresto del database.
**Topics**
+ [Versioni del motore supportate](#proactive-insights.history-list.context.supported)
+ [Contesto](#proactive-insights.history-list.context)
+ [Probabili cause di questo problema](#proactive-insights.history-list.causes)
+ [Azioni](#proactive-insights.history-list.actions)
+ [Metriche pertinenti](#proactive-insights.history-list.metrics)
## Versioni del motore supportate
Queste informazioni approfondite sono supportate per tutte le versioni di Aurora MySQL.
## Contesto
Il sistema di transazioni InnoDB gestisce il controllo della concorrenza multiversione (MVCC). Quando una riga viene modificata, la versione precedente alla modifica dei dati da modificare viene archiviata come record di annullamento in un log di annullamenti. Ogni record di annullamento ha un riferimento al record di ripristino precedente, formando un elenco collegato.
L'elenco della cronologia di InnoDB è un elenco globale dei log di annullamento per le transazioni sottoposte a commit. MySQL utilizza l'elenco della cronologia per eliminare i record e le pagine di log quando le transazioni non richiedono più la cronologia. La lunghezza dell'elenco della cronologia è il numero totale di log di annullamento che contengono modifiche nell'elenco della cronologia. Ogni log contiene una o più modifiche. Se la lunghezza dell'elenco della cronologia di InnoDB aumenta in modo significativo, indicando un numero elevato di precedenti versioni di riga, la chiusura delle query e l'arresto del database diventano più lenti.
## Probabili cause di questo problema
Le cause tipiche di un lungo elenco della cronologia sono:
+ Transazioni di lunga durata, in lettura o scrittura
+ Carico elevato in scrittura
## Azioni
Consigliamo azioni diverse a seconda delle cause degli approfondimenti.
**Topics**
+ [Non iniziare alcuna operazione che comporti l'arresto del database finché non diminuiscono le dimensioni dell'elenco della cronologia di InnoDB](#proactive-insights.history-list.actions.no-shutdown)
+ [Identificare e terminare le transazioni di lunga durata](#proactive-insights.history-list.actions.long-txn)
+ [Usa Approfondimenti sulle prestazioni per individuare i principali host e i migliori utenti.](#proactive-insights.history-list.actions.top-PI)
### Non iniziare alcuna operazione che comporti l'arresto del database finché non diminuiscono le dimensioni dell'elenco della cronologia di InnoDB
Poiché un lungo elenco della cronologia di InnoDB rallenta l'arresto del database, riduci le dimensioni dell'elenco prima di iniziare le relative operazioni. Queste operazioni includono gli aggiornamenti della versione principale del database.
### Identificare e terminare le transazioni di lunga durata
Puoi individuare le transazioni di lunga durata eseguendo la query `information_schema.innodb_trx`.
**Nota**
Assicurarsi anche di cercare transazioni di lunga durata nelle repliche di lettura.
**Per identificare e terminare le transazioni di lunga durata**
1. Nel client SQL esegui la seguente query:
```
SELECT a.trx_id,
a.trx_state,
a.trx_started,
TIMESTAMPDIFF(SECOND,a.trx_started, now()) as "Seconds Transaction Has Been Open",
a.trx_rows_modified,
b.USER,
b.host,
b.db,
b.command,
b.time,
b.state
FROM information_schema.innodb_trx a,
information_schema.processlist b
WHERE a.trx_mysql_thread_id=b.id
AND TIMESTAMPDIFF(SECOND,a.trx_started, now()) > 10
ORDER BY trx_started
```
1. Terminare ogni transazione di lunga durata con la stored procedure [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill).
### Usa Approfondimenti sulle prestazioni per individuare i principali host e i migliori utenti.
Ottimizza le transazioni in modo che un numero elevato di righe modificate venga immediatamente sottoposto a commit.
## Metriche pertinenti
A questo approfondimento è correlato il seguente parametro:
+ `trx_rseg_history_len`: questa metrica del contatore può essere visualizzata in Approfondimenti sulle prestazioni, oltre che nella tabella `INFORMATION_SCHEMA.INNODB_METRICS`. Per ulteriori informazioni, consulta [InnoDB INFORMATION\$1SCHEMA metrics table](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-metrics-table.html) nella documentazione di MySQL.
+ `RollbackSegmentHistoryListLength`— Questa CloudWatch metrica di Amazon misura i log di annullamento che registrano le transazioni impegnate con record contrassegnati da eliminare. Questi record sono pianificati per essere elaborati dall'operazione di rimozione InnoDB. La metrica `trx_rseg_history_len` ha lo stesso valore di `RollbackSegmentHistoryListLength`.
+ `PurgeBoundary`: numero di transazione fino al quale è consentita l’eliminazione da InnoDB. Se questa CloudWatch metrica non avanza per lunghi periodi di tempo, è una buona indicazione che l'eliminazione di InnoDB è bloccata da transazioni di lunga durata. Per indagare, controlla le transazioni attive sul cluster di database Aurora MySQL. Questa metrica è disponibile solo per Aurora MySQL versione 2.11 e successive e versione 3.08 e successive.
+ `PurgeFinishedPoint`: numero di transazione fino al quale viene eseguita l’eliminazione da InnoDB. Questa CloudWatch metrica può aiutarti a esaminare la velocità con cui procede l'eliminazione da InnoDB. Questa metrica è disponibile solo per Aurora MySQL versione 2.11 e successive e versione 3.08 e successive.
+ `TransactionAgeMaximum`: età della transazione attiva in esecuzione meno recente. Questa CloudWatch metrica è disponibile solo per Aurora MySQL versione 3.08 e successive.
+ `TruncateFinishedPoint`: numero di transazione fino al quale viene eseguito l’annullamento del troncamento. Questa CloudWatch metrica è disponibile solo per Aurora MySQL versione 2.11 e successive e versione 3.08 e successive.
Per ulteriori informazioni sulle metriche, consulta. CloudWatch [Parametri a livello di istanza per Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)
# Il database sta creando tabelle temporanee su disco
L'utilizzo recente delle tabelle temporanee su disco è aumentato in modo significativo, fino a*percentage*. Il database crea circa tabelle *number* temporanee al secondo. Ciò potrebbe influire sulle prestazioni e aumentare le operazioni su disco*db-instance*.
**Topics**
+ [Versioni del motore supportate](#proactive-insights.temp-tables.context.supported)
+ [Contesto](#proactive-insights.temp-tables.context)
+ [Probabili cause di questo problema](#proactive-insights.temp-tables.causes)
+ [Azioni](#proactive-insights.temp-tables.actions)
+ [Metriche pertinenti](#proactive-insights.temp-tables.metrics)
## Versioni del motore supportate
Queste informazioni approfondite sono supportate per tutte le versioni di Aurora MySQL.
## Contesto
A volte è necessario che il server MySQL crei una tabella temporanea interna durante l'elaborazione di una query. può contenere una tabella temporanea interna in memoria, dove può essere elaborata dal motore di archiviazione MEMORY o archiviata su disco TempTable da InnoDB. Per ulteriori informazioni, consulta [Uso della tabella temporanea interna in MySQL](https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html) nel *Manuale di riferimento di MySQL*.
## Probabili cause di questo problema
Un aumento delle tabelle temporanee su disco indica l'uso di query complesse. Se la memoria configurata non è sufficiente per archiviare le tabelle temporanee in memoria, Aurora MySQL crea le tabelle su disco. Ciò può influire sulle prestazioni e aumentare le operazioni del disco.
## Azioni
Consigliamo azioni diverse a seconda delle cause degli approfondimenti.
+ Per versione 3, si consiglia di utilizzare il motore di archiviazione. TempTable
+ Ottimizza le query in modo da restituire meno dati selezionando solo le colonne necessarie.
Se attivi lo schema delle prestazioni con tutti gli strumenti `statement` abilitati e temporizzati, puoi eseguire la query `SYS.statements_with_temp_tables` per recuperare l'elenco delle query che utilizzano le tabelle temporanee. Per ulteriori informazioni, consulta [Prerequisiti per l'utilizzo dello schema sys](https://dev.mysql.com/doc/refman/8.0/en/sys-schema-prerequisites.html) nella documentazione di MySQL.
+ Prendi in considerazione l'indicizzazione delle colonne coinvolte nelle operazioni di ordinamento e raggruppamento.
+ Riscrivi le query per evitare le colonne `BLOB` e `TEXT`. Queste colonne utilizzano sempre il disco.
+ Ottimizza i parametri del database `tmp_table_size` e `max_heap_table_size`.
Il valore predefinito di questi parametri è 16 MiB. Quando si utilizza il motore di archiviazione MEMORY per tabelle temporanee in memoria, la dimensione massima è definita dal valore `tmp_table_size` o `max_heap_table_size`, a seconda di quale sia il più piccolo. Quando viene raggiunta questa dimensione massima, MySQL converte automaticamente la tabella temporanea interna in memoria in una tabella temporanea interna di InnoDB su disco. Per ulteriori informazioni, consulta [Utilizzare il motore TempTable di storage su Amazon RDS for MySQL e Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).
**Nota**
Quando si creano in modo esplicito tabelle MEMORY con CREATE TABLE, solo la variabile `max_heap_table_size` determina la dimensione massima di una tabella. Inoltre, non è prevista la conversione in un formato su disco.
## Metriche pertinenti
A questo approfondimento sono correlati i seguenti parametri di Approfondimenti sulle prestazioni:
+ Created\$1tmp\$1disk\$1tables
+ Created\$1tmp\$1tables
Per ulteriori informazioni, consulta [Created\$1tmp\$1disk\$1tables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Created_tmp_disk_tables) nella documentazione di MySQL.