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à. # Best practice per le prestazioni e il dimensionamento di Aurora MySQL È possibile applicare le best practice seguenti per migliorare le prestazioni e la scalabilità dei cluster Aurora MySQL. **Topics** + [Utilizzo delle classi di istanza T per lo sviluppo e i test](#AuroraMySQL.BestPractices.T2Medium) + [Ottimizzazione delle query di join indicizzate Aurora MySQL con prefetch asincrono delle chiavi](#Aurora.BestPractices.AKP) + [Ottimizzazione di grandi query di join Aurora MySQL con hash join](#Aurora.BestPractices.HashJoin) + [Utilizzo di Amazon Aurora per dimensionare le letture per il database MySQL](#AuroraMySQL.BestPractices.ReadScaling) + [Ottimizzazione delle operazioni di timestamp](#AuroraMySQL.BestPractices.Performance.TimeZone) + [Errori di overflow dell’ID di indice virtuale](#AuroraMySQL.BestPractices.Performance.VirtualIndexIDOverflow) ## Utilizzo delle classi di istanza T per lo sviluppo e i test Le istanze Amazon Aurora MySQL che utilizzano le classi di istanza database `db.t2`, `db.t3` o `db.t4g` sono ideali per applicazioni che non supportano un carico di lavoro elevato per una quantità di tempo significativa. Le istanze T sono progettate per offrire prestazioni di base moderate e garantire prestazioni notevolmente maggiori se il carico di lavoro lo richiede. Sono concepite per carichi di lavoro che non utilizzano completamente la CPU spesso o in maniera regolare, ma che occasionalmente necessitano di un incremento delle prestazioni. Consigliamo di utilizzare le classi di istanza database T solo per i server di sviluppo e test o altri server non di produzione. Per ulteriori informazioni sulle classi di istanze T, consulta [Istanze espandibili](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html). Se il cluster Aurora è più grande di 40 TB, non utilizzare le classi di istanza T. Quando il database dispone di un volume elevato di dati, il sovraccarico di memoria per la gestione degli oggetti dello schema può superare la capacità di un'istanza T. Non abilitare lo schema di prestazioni MySQL sulle istanze T di Amazon Aurora MySQL. In caso contrario, è possibile che la memoria disponibile per l'istanza T potrebbe esaurirsi. **Suggerimento** Se il database a volte è inattivo e altre volte ha un notevole carico di lavoro, puoi utilizzare Aurora Serverless v2 come alternativa alle istanze T. Con Aurora Serverless v2 puoi definire un intervallo di capacità e Aurora dimensiona automaticamente il database in base al carico di lavoro corrente. Per informazioni dettagliate sull'utilizzo, consulta [Uso di Aurora Serverless v2](aurora-serverless-v2.md). Per le versioni del motore del database che puoi utilizzare con Aurora Serverless v2, consulta [Requisiti e limitazioni per Aurora Serverless v2](aurora-serverless-v2.requirements.md). Quando si utilizza un'istanza T come istanza di database in un cluster di database Aurora MySQL, si consiglia quanto segue: + Utilizza la stessa classe di istanza database per tutte le istanze nel cluster di database. Ad esempio, se si utilizza `db.t2.medium` per l'istanza di scrittura, allora si consiglia di usare `db.t2.medium` anche per le istanze di lettura. + Non regolare le impostazioni di configurazione relative alla memoria, ad esempio `innodb_buffer_pool_size`. Aurora utilizza un insieme altamente sintonizzato di valori di default per i buffer di memoria sulle istanze T. Questi valoridi di default speciali sono necessari per consentire l'esecuzione di Aurora su istanze vincolate dalla memoria. Se si modificano le impostazioni relative alla memoria su un'istanza T, è molto più probabile che si verifichino out-of-memory condizioni, anche se la modifica è intesa ad aumentare le dimensioni del buffer. + Eseguire il monitoraggio del saldo del credito CPU (`CPUCreditBalance`) per garantire che il relativo livello sia sostenibile. In altre parole, i crediti CPU vengono accumulati alla stessa velocità con cui vengono utilizzati. Una volta esauriti i crediti CPU per un'istanza, si assisterà a un calo immediato nella CPU disponibile e a un aumento della latenza di lettura e scrittura per l'istanza. Questa situazione provoca un'importante riduzione delle prestazioni complessive dell'istanza. Se il livello del saldo del credito CPU non è sostenibile, consigliamo di modificare l'istanza database in modo da utilizzare una delle classi di istanza database R supportate (dimensionamento del calcolo). Per ulteriori informazioni sui parametri di monitoraggio, consulta [Visualizzazione delle metriche nella console Amazon RDS](USER_Monitoring.md). + Monitora il ritardo di replica (`AuroraReplicaLag`) tra l'istanza di scrittura e le istanze di lettura. Se un'istanza di lettura esaurisce i crediti della CPU prima dell'istanza si scrittura, il ritardo risultante può causare il riavvio frequente dell'istanza di lettura. Si tratta di un risultato comune nei casi in cui un'applicazione dispone di un carico elevato di operazioni di lettura distribuito tra le istanze di lettura, allo stesso tempo che l'istanza di scrittura presenta un carico minimo di operazioni di scrittura. Se il ritardo della replica aumenta notevolmente, sarà necessario verificare che il saldo del credito CPU per le istanze di lettura nel cluster DB non sia esaurito. Se il livello del saldo del credito CPU non è sostenibile, consigliamo di modificare l'istanza database in modo da utilizzare una delle classi di istanza database R supportate (dimensionamento del calcolo). + Mantenere il numero di inserimenti per transazione al di sotto di 1 milione per i cluster di database per cui è abilitata la registrazione binaria. Se il gruppo di parametri del cluster DB per il cluster DB ha il `binlog_format` parametro impostato su un valore diverso da`OFF`, il cluster di DB potrebbe presentare out-of-memory delle condizioni se il cluster DB riceve transazioni che contengono più di 1 milione di righe da inserire. È possibile monitorare il parametro della memoria da liberare (`FreeableMemory`) per determinare se la memoria disponibile per il cluster di database sta per esaurire. Controllando quindi il parametro delle operazioni di scrittura (`VolumeWriteIOPS`) sarà possibile verificare se l'istanza di scrittura riceve un carico elevato di operazioni di scrittura. In tal caso, consigliamo di aggiornare l'applicazione per limitare gli inserimenti in una transazione a un numero inferiore a 1 milione. In alternativa, è possibile modificare l'istanza in modo da utilizzare una delle classi di istanza database R supportate (dimensionamento del calcolo). ## Ottimizzazione delle query di join indicizzate Aurora MySQL con prefetch asincrono delle chiavi Aurora MySQL può utilizzare il prefetch asincrono delle chiavi per migliorare le prestazioni delle query che eseguono il join delle tabelle negli indici. Questa funzionalità migliora le prestazioni anticipando le righe necessarie per eseguire query in cui una query JOIN richieda l'uso dell'algoritmo di join Batched Key Access (BKA) e le funzionalità di ottimizzazione Multi-Range Read (MRR). Per ulteriori informazioni su BKA e MRR, consulta [Block Nested-Loop and Batched Key Access Joins](https://dev.mysql.com/doc/refman/5.6/en/bnl-bka-optimization.html) e [Multi-Range Read Optimization](https://dev.mysql.com/doc/refman/5.6/en/mrr-optimization.html) nella documentazione di MySQL. Per trarre vantaggio dalla funzionalità di prefetch asincrono delle chiavi, è necessario che una query utilizzi sia gli algoritmi BKA sia le funzionalità MRR. Tale query viene in genere eseguita quando la clausola JOIN di una query utilizza un indice secondario, ma richiede anche alcune colonne dell'indice principale. Puoi ad esempio utilizzare il prefetch asincrono delle chiavi quando una clausola JOIN rappresenta un equijoin sui valori di indice tra una tabella esterna di piccole dimensioni e una interna di dimensioni maggiori, in cui l'indice è altamente selettivo nella tabella più grande. Il prefetch asincrono delle chiavi interagisce con BKA e MRR per eseguire una ricerca nell'indice da secondario a principale durante la valutazione di una clausola JOIN. Il prefetch asincrono delle chiavi identifica le righe necessarie per eseguire la query durante la valutazione della clausola JOIN. Utilizza quindi un thread in background per caricare in modo asincrono le pagine contenenti le righe in memoria prima di eseguire la query. Il prefetch asincrono delle chiavi è disponibile per Aurora MySQL versione 2.10 e successive e per la versione 3. Per ulteriori informazioni sulle versioni di Aurora MySQL, consulta [Aggiornamenti del motore del database per Amazon Aurora MySQLVersioni beta e con supporto a lungo termine (LTS, Long-Term Support) di Amazon Aurora MySQL](AuroraMySQL.Updates.md). ### Abilitazione del prefetch asincrono delle chiavi È possibile abilitare la funzionalità di prefetch asincrono delle chiavi impostando `aurora_use_key_prefetch`, una variabile del server MySQL, su `on`. Per impostazione predefinita, questo valore è impostato su `on`. È tuttavia possibile abilitare il prefetch asincrono delle chiavi solo dopo aver abilitato anche l'algoritmo di join BKA e aver disabilitato la funzionalità MRR basata sui costi. A tale scopo, è necessario impostare i seguenti valori per `optimizer_switch`, una variabile di server MySQL: + Imposta `batched_key_access` su `on`. Questo valore controlla l'utilizzo dell'algoritmo di join BKA. Per impostazione predefinita, questo valore è impostato su `off`. + Imposta `mrr_cost_based` su `off`. Questo valore controlla l'utilizzo della funzionalità MRR basata sui costi. Per impostazione predefinita, questo valore è impostato su `on`. È attualmente possibile impostare questi valori solo a livello di sessione. Il seguente esempio illustra come impostare questi valori in modo da abilitare la funzionalità di prefetch asincrono delle chiavi per la sessione corrente eseguendo le istruzioni SET. ``` mysql> set @@session.aurora_use_key_prefetch=on; mysql> set @@session.optimizer_switch='batched_key_access=on,mrr_cost_based=off'; ``` In modo analogo, è possibile utilizzare le istruzioni SET per disabilitare la funzionalità di prefetch asincrono delle chiavi e l'algoritmo di join BKA e riabilitare la funzionalità MRR basata sui costi per la sessione corrente, come mostrato nell'esempio seguente. ``` mysql> set @@session.aurora_use_key_prefetch=off; mysql> set @@session.optimizer_switch='batched_key_access=off,mrr_cost_based=on'; ``` Per ulteriori informazioni sulle opzioni di ottimizzazione **batched\$1key\$1access** e **mrr\$1cost\$1based**, consulta [Switchable Optimizations](https://dev.mysql.com/doc/refman/5.6/en/switchable-optimizations.html) nella documentazione di MySQL. ### Ottimizzazione delle query per il prefetch asincrono delle chiavi È possibile verificare se una query può trarre vantaggio dalla funzionalità di prefetch asincrono delle chiavi. A tale scopo, utilizza l'istruzione `EXPLAIN` per profilare la query prima di eseguirla. L'istruzione `EXPLAIN` fornisce informazioni sul piano di esecuzione da utilizzare per una query specificata. Nell'output dell'istruzione `EXPLAIN` la colonna `Extra` descrive le informazioni aggiuntive incluse nel piano di esecuzione. Se la funzionalità di prefetch asincrono delle chiavi si applica a una tabella utilizzata nella query, questa colonna include uno dei seguenti valori: + `Using Key Prefetching` + `Using join buffer (Batched Key Access with Key Prefetching)` Il seguente esempio illustra l'utilizzo di `EXPLAIN` per visualizzare il piano di esecuzione per una query che può sfruttare il prefetch asincrono delle chiavi. ``` mysql> explain select sql_no_cache -> ps_partkey, -> sum(ps_supplycost * ps_availqty) as value -> from -> partsupp, -> supplier, -> nation -> where -> ps_suppkey = s_suppkey -> and s_nationkey = n_nationkey -> and n_name = 'ETHIOPIA' -> group by -> ps_partkey having -> sum(ps_supplycost * ps_availqty) > ( -> select -> sum(ps_supplycost * ps_availqty) * 0.0000003333 -> from -> partsupp, -> supplier, -> nation -> where -> ps_suppkey = s_suppkey -> and s_nationkey = n_nationkey -> and n_name = 'ETHIOPIA' -> ) -> order by -> value desc; +----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+ | 1 | PRIMARY | nation | ALL | PRIMARY | NULL | NULL | NULL | 25 | 100.00 | Using where; Using temporary; Using filesort | | 1 | PRIMARY | supplier | ref | PRIMARY,i_s_nationkey | i_s_nationkey | 5 | dbt3_scale_10.nation.n_nationkey | 2057 | 100.00 | Using index | | 1 | PRIMARY | partsupp | ref | i_ps_suppkey | i_ps_suppkey | 4 | dbt3_scale_10.supplier.s_suppkey | 42 | 100.00 | Using join buffer (Batched Key Access with Key Prefetching) | | 2 | SUBQUERY | nation | ALL | PRIMARY | NULL | NULL | NULL | 25 | 100.00 | Using where | | 2 | SUBQUERY | supplier | ref | PRIMARY,i_s_nationkey | i_s_nationkey | 5 | dbt3_scale_10.nation.n_nationkey | 2057 | 100.00 | Using index | | 2 | SUBQUERY | partsupp | ref | i_ps_suppkey | i_ps_suppkey | 4 | dbt3_scale_10.supplier.s_suppkey | 42 | 100.00 | Using join buffer (Batched Key Access with Key Prefetching) | +----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+ 6 rows in set, 1 warning (0.00 sec) ``` Per ulteriori informazioni sul formato di output `EXPLAIN`, consulta l'argomento relativo al [formato di output EXPLAIN esteso](https://dev.mysql.com/doc/refman/8.0/en/explain-extended.html) nella documentazione di MySQL. ## Ottimizzazione di grandi query di join Aurora MySQL con hash join Se devi eseguire il join di una grande quantità di dati tramite una query equijoin, l'utilizzo di un hash join può migliorare le prestazioni della query. Puoi abilitare gli hash join per Aurora MySQL. Una colonna hash join può essere una qualsiasi espressione complessa. Di seguito sono indicati i modi per eseguire il confronto tra i tipi di dati in una colonna hash join: + È possibile confrontare qualsiasi elemento nella categoria dei tipi di dati numerici precisi, ad esempio `int`, `bigint`, `numeric` e `bit`. + È possibile confrontare qualsiasi elemento nella categoria dei tipi di dati numerici di approssimazione, ad esempio `float` e `double`. + È possibile confrontare elementi nei tipi di stringa, se i tipi di stringa dispongono dello stesso set di caratteri e delle stesse regole di confronto. + È possibile confrontare elementi con tipi di dati data e timestamp, se i tipi corrispondono. **Nota** Non è possibile confrontare i tipi di dati in categorie differenti. Di seguito sono indicate le limitazioni che si applicano agli hash join per Aurora MySQL: + Gli outer join sinistri-destri non sono supportati per Aurora MySQL versione 2, ma sono supportati per la versione 3. + I semi-join come le query secondarie non sono supportati, a meno che non vengano prima materializzate le query secondarie. + Aggiornamenti o eliminazioni di più tabelle non sono supportati. **Nota** Aggiornamenti o eliminazioni di tabelle singole sono supportati. + Le colonne con tipi di dati BLOB e spaziali non possono essere colonne join in un hash join. ### Abilitazione di hash join Per abilitare gli hash join: + Aurora MySQL versione 2: imposta il parametro di database o il parametro del cluster di database `aurora_disable_hash_join` su `0`. La disattivazione di `aurora_disable_hash_join` imposta il valore di `optimizer_switch` su `hash_join=on`. + Aurora MySQL versione 3: imposta il parametro del server MySQL `optimizer_switch` su `block_nested_loop=on`. Gli hash join sono attivati per impostazione predefinita in Aurora MySQL Versione 3 e Aurora MySQL versione 2. Nell'esempio seguente viene illustrato come abilitare gli hash join per Aurora MySQL versione 3. È possibile rilasciare l’istruzione `select @@optimizer_switch` per prima cosa per vedere quali altre impostazioni sono presenti nella stringa dei parametri di `SET`. Aggiornamento di un'impostazione nel parametro di `optimizer_switch` non cancella o modifica le altre impostazioni. ``` mysql> SET optimizer_switch='block_nested_loop=on'; ``` **Nota** Per Aurora MySQL Versione 3, il supporto hash join è disponibile in tutte le versioni secondarie ed è attivato per impostazione predefinita. Per Aurora MySQL versione 2, il supporto hash join è disponibile in tutte le versioni secondarie. In Aurora MySQL versione 2, la funzionalità di join hash è sempre controllata dal valore `aurora_disable_hash_join`. Con questa impostazione, l'ottimizzatore sceglie di utilizzare un hash join in base al costo, alle caratteristiche della query e alla disponibilità delle risorse. Se la stima dei costi non è corretta, puoi imporre all'ottimizzatore di scegliere un hash join, impostando `hash_join_cost_based`, una variabile del server MySQL, su `off`. L'esempio seguente illustra come imporre all'ottimizzatore di scegliere un hash join. ``` mysql> SET optimizer_switch='hash_join_cost_based=off'; ``` **Nota** Questa impostazione sostituisce le decisioni dell'ottimizzatore basato sui costi. Sebbene l'impostazione possa essere utile per il test e lo sviluppo, si consiglia di non utilizzarla in produzione. ### Ottimizzazione delle query per gli hash join Per sapere se una query può utilizzare un hash join, è possibile utilizzare in primo luogo l'istruzione `EXPLAIN` per profilare la query. L'istruzione `EXPLAIN` fornisce informazioni sul piano di esecuzione da utilizzare per una query specificata. Nell'output dell'istruzione `EXPLAIN` la colonna `Extra` descrive le informazioni aggiuntive incluse nel piano di esecuzione. Se un hash join si applica alle tabelle utilizzate nella query, questa colonna include valori simili a quelli indicato di seguito: + `Using where; Using join buffer (Hash Join Outer table table1_name)` + `Using where; Using join buffer (Hash Join Inner table table2_name)` Il seguente esempio illustra l'utilizzo di EXPLAIN per visualizzare il piano di esecuzione per una query con hash join. ``` mysql> explain SELECT sql_no_cache * FROM hj_small, hj_big, hj_big2 -> WHERE hj_small.col1 = hj_big.col1 and hj_big.col1=hj_big2.col1 ORDER BY 1; +----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+ | 1 | SIMPLE | hj_small | ALL | NULL | NULL | NULL | NULL | 6 | Using temporary; Using filesort | | 1 | SIMPLE | hj_big | ALL | NULL | NULL | NULL | NULL | 10 | Using where; Using join buffer (Hash Join Outer table hj_big) | | 1 | SIMPLE | hj_big2 | ALL | NULL | NULL | NULL | NULL | 15 | Using where; Using join buffer (Hash Join Inner table hj_big2) | +----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+ 3 rows in set (0.04 sec) ``` Nell'output `Hash Join Inner table` indica la tabella utilizzata per creare la tabella hash e `Hash Join Outer table` indica la tabella utilizzata per il probe della tabella hash. Per ulteriori informazioni sul formato di output `EXPLAIN` esteso, consulta [Formato di output EXPLAIN esteso](https://dev.mysql.com/doc/refman/8.0/en/explain-extended.html) nella documentazione di MySQL. In Aurora MySQL 2.08 e versioni successive, è possibile utilizzare gli hint SQL per determinare se una query utilizza o meno hash join e quali tabelle utilizzare per i lati di build e probe del join. Per informazioni dettagliate, vedi [Suggerimenti di Aurora MySQL](AuroraMySQL.Reference.Hints.md). ## Utilizzo di Amazon Aurora per dimensionare le letture per il database MySQL Puoi utilizzare Amazon Aurora con l'istanza database MySQL per usufruire delle funzionalità di dimensionamento della lettura di Amazon Aurora ed espandere il reale carico di lavoro della tua istanza database MySQL. Per utilizzare Aurora per ridimensionare la lettura dell'istanza database MySQL, crea un cluster di database Aurora MySQL e rendilo una replica di lettura per l'istanza database MySQL. Quindi connettiti al cluster Aurora MySQL per elaborare le query di lettura. Il database di origine può essere un'istanza database RDS for MySQL o un database MySQL in esecuzione esternamente a Amazon RDS. Per ulteriori informazioni, consulta [Dimensionamento delle letture per il database MySQL con Amazon Aurora](AuroraMySQL.Replication.ReadScaling.md). ## Ottimizzazione delle operazioni di timestamp Quando il valore della variabile di sistema `time_zone` è impostato su `SYSTEM`, ogni chiamata di funzione MySQL che richiede un calcolo del fuso orario effettua una chiamata alla libreria di sistema. Quando esegui istruzioni SQL che restituiscono o modificano tali valori `TIMESTAMP` in caso di elevata concorrenza, è possibile che si verifichi un aumento della latenza, dei conflitti di blocco e dell'utilizzo della CPU. Per ulteriori informazioni, consulta [time\$1zone](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_time_zone) nella documentazione di MySQL. Per evitare questo comportamento, consigliamo di modificare il valore del parametro `time_zone` del cluster database impostandolo su `UTC`. Per ulteriori informazioni, consulta [Modifica dei parametri in un gruppo di parametri del cluster DB in Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md). Sebbene il parametro `time_zone` sia dinamico (non richiede il riavvio del server di database), il nuovo valore viene utilizzato solo per le nuove connessioni. Per assicurarti che tutte le connessioni siano aggiornate in modo che venga utilizzato il nuovo valore `time_zone`, consigliamo di riciclare le connessioni alle applicazioni dopo aver aggiornato il parametro del cluster database. ## Errori di overflow dell’ID di indice virtuale Aurora MySQL limita i valori per l'indice virtuale IDs a 8 bit per prevenire un problema causato dal formato di annullamento in MySQL. Se un indice supera il limite impostato per l’ID di indice virtuale, il cluster potrebbe non essere disponibile. Quando un indice si avvicina al limite impostato per l’ID di indice virtuale oppure quando tenti di creare un indice superiore al limite impostato per l’ID di indice virtuale, RDS potrebbe generare il codice di errore `63955` o il codice di avviso `63955`. Per risolvere un errore relativo al limite impostato per l’ID di indice virtuale, si consiglia di creare nuovamente il database con un dump logico e quindi di eseguire il ripristino. Per ulteriori informazioni sul dump e il ripristino logici per Amazon Aurora MySQL[, consulta Migrare database di grandi dimensioni su Amazon Aurora MySQL usando](https://aws.amazon.com/blogs/database/migrate-very-large-databases-to-amazon-aurora-mysql-using-mydumper-and-myloader/) and. MyDumper MyLoader Per ulteriori informazioni sull’accesso ai log degli errori in Amazon Aurora, consulta [Monitoraggio dei file di log di Amazon Aurora](USER_LogAccess.md).