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