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