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à.
Identificazione delle istruzioni che utilizzano la funzione di query in parallelo per Aurora MySQL
In regola generale, non è necessario eseguire specifiche operazioni per utilizzare le query in parallelo. Quando una query soddisfa i requisiti essenziali della funzionalità di query in parallelo, l'ottimizzatore di query decide automaticamente se utilizzare tale funzionalità per ogni query.
Se esegui dei test in un ambiente di sviluppo o di test, è possibile che la funzione di query in parallelo non sia utilizzata in quanto le tabelle non contengono una quantità sufficiente di righe o volumi di dati. I dati associati alle tabelle, soprattutto quelle create recentemente per effettuare dei test, possono anche trovarsi interamente nel pool di buffer.
Durante il monitoraggio o l'ottimizzazione delle prestazioni del cluster, devi determinare se le query in parallelo sono utilizzate nei contesti appropriati. È possibile che sia necessario modificare lo schema di database, le impostazioni, le query SQL o persino la topologia del cluster e le impostazioni di connessione dell'applicazione per utilizzare questa funzionalità.
Per verificare se una query sta utilizzando la funzionalità di query in parallelo, consulta il piano di esecuzione della query (denominato anche "piano explain") eseguendo l'istruzione EXPLAINEXPLAIN per le query parallele, consulta Costrutti SQL per query in parallelo in Aurora MySQL.
L'esempio seguente illustra la differenza tra un piano query tradizionale e un piano di query in parallelo. Questo piano di spiegazione è da Query 3 del benchmark TPC-H. Molti degli esempi di query in questa sezione utilizzano tabelle del set di dati TPC-H. È possibile ottenere le definizioni di tabella, le query e il programma dbgen che genera dati di esempio dal sito Web TPC-H
EXPLAIN SELECT l_orderkey, sum(l_extendedprice * (1 - l_discount)) AS revenue, o_orderdate, o_shippriority FROM customer, orders, lineitem WHERE c_mktsegment = 'AUTOMOBILE' AND c_custkey = o_custkey AND l_orderkey = o_orderkey AND o_orderdate < date '1995-03-13' AND l_shipdate > date '1995-03-13' GROUP BY l_orderkey, o_orderdate, o_shippriority ORDER BY revenue DESC, o_orderdate LIMIT 10;
Per impostazione predefinita, la query potrebbe avere un piano simile al seguente. Se il join hash non viene visualizzato nel piano di query, assicurarsi che l'ottimizzazione sia abilitata per prima.
+----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+
| 1 | SIMPLE | customer | NULL | ALL | NULL | NULL | NULL | NULL | 1480234 | 10.00 | Using where; Using temporary; Using filesort |
| 1 | SIMPLE | orders | NULL | ALL | NULL | NULL | NULL | NULL | 14875240 | 3.33 | Using where; Using join buffer (Block Nested Loop) |
| 1 | SIMPLE | lineitem | NULL | ALL | NULL | NULL | NULL | NULL | 59270573 | 3.33 | Using where; Using join buffer (Block Nested Loop) |
+----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+
Per Aurora MySQL versione 3, è possibile abilitare il join hash a livello di sessione eseguendo la seguente istruzione.
SET optimizer_switch='block_nested_loop=on';
Per Aurora MySQL versione 2.09 e successive, è necessario impostare il parametro di database aurora_disable_hash_join o il parametro del cluster di database su 0 (disattivato). La disattivazione di aurora_disable_hash_join imposta il valore di optimizer_switch su hash_join=on.
Dopo aver attivato il join hash, prova a eseguire nuovamente l'istruzione EXPLAIN. Per informazioni su come utilizzare i join hash in modo efficace, vedere Ottimizzazione di grandi query di join Aurora MySQL con hash join.
Quando la funzionalità di query in parallelo di join hash è disabilitata, la query può avere un piano simile al seguente, che utilizza un hash join ma non le query in parallelo.
+----+-------------+----------+...+-----------+-----------------------------------------------------------------+
| id | select_type | table |...| rows | Extra |
+----+-------------+----------+...+-----------+-----------------------------------------------------------------+
| 1 | SIMPLE | customer |...| 5798330 | Using where; Using index; Using temporary; Using filesort |
| 1 | SIMPLE | orders |...| 154545408 | Using where; Using join buffer (Hash Join Outer table orders) |
| 1 | SIMPLE | lineitem |...| 606119300 | Using where; Using join buffer (Hash Join Outer table lineitem) |
+----+-------------+----------+...+-----------+-----------------------------------------------------------------+
Quando la funzionalità di query in parallelo è abilitata, due fasi di questo piano possono utilizzare l'ottimizzazione mediante query in parallelo, come indicato dalla colonna Extra nell'output EXPLAIN. L'elaborazione che implica un numero elevato di operazioni I/O e un utilizzo intensivo della CPU per tali fasi viene trasferita al livello di storage.
+----+...+--------------------------------------------------------------------------------------------------------------------------------+
| id |...| Extra |
+----+...+--------------------------------------------------------------------------------------------------------------------------------+
| 1 |...| Using where; Using index; Using temporary; Using filesort |
| 1 |...| Using where; Using join buffer (Hash Join Outer table orders); Using parallel query (4 columns, 1 filters, 1 exprs; 0 extra) |
| 1 |...| Using where; Using join buffer (Hash Join Outer table lineitem); Using parallel query (4 columns, 1 filters, 1 exprs; 0 extra) |
+----+...+--------------------------------------------------------------------------------------------------------------------------------+
Per informazioni su come interpretare l'output EXPLAIN per una query in parallelo e sulle parti delle istruzioni SQL a cui le query in parallelo possono essere applicate, consulta Costrutti SQL per query in parallelo in Aurora MySQL.
L'esempio di output seguente mostra i risultati dell'esecuzione della query precedente su un'istanza db.r4.2xlarge con un pool di buffer a freddo. L'esecuzione della query risulta molto più rapida con la funzionalità di query in parallelo.
Nota
Poiché la durata dipende da molti fattori ambientali, i risultati potrebbero essere differenti. Esegui sempre dei test di prestazioni personali per confermare i risultati con il tuo ambiente, carico di lavoro e così via.
-- Without parallel query
+------------+-------------+-------------+----------------+
| l_orderkey | revenue | o_orderdate | o_shippriority |
+------------+-------------+-------------+----------------+
| 92511430 | 514726.4896 | 1995-03-06 | 0 |
.
.
| 28840519 | 454748.2485 | 1995-03-08 | 0 |
+------------+-------------+-------------+----------------+
10 rows in set (24 min 49.99 sec)
-- With parallel query
+------------+-------------+-------------+----------------+
| l_orderkey | revenue | o_orderdate | o_shippriority |
+------------+-------------+-------------+----------------+
| 92511430 | 514726.4896 | 1995-03-06 | 0 |
.
.
| 28840519 | 454748.2485 | 1995-03-08 | 0 |
+------------+-------------+-------------+----------------+
10 rows in set (1 min 49.91 sec)
Molti degli esempi di query in questa sezione utilizzano le tabelle di questo set di dati TPC-H, in particolare la tabella PART, che comporta 20 milioni di righe e la definizione seguente.
+---------------+---------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+---------------+------+-----+---------+-------+
| p_partkey | int(11) | NO | PRI | NULL | |
| p_name | varchar(55) | NO | | NULL | |
| p_mfgr | char(25) | NO | | NULL | |
| p_brand | char(10) | NO | | NULL | |
| p_type | varchar(25) | NO | | NULL | |
| p_size | int(11) | NO | | NULL | |
| p_container | char(10) | NO | | NULL | |
| p_retailprice | decimal(15,2) | NO | | NULL | |
| p_comment | varchar(23) | NO | | NULL | |
+---------------+---------------+------+-----+---------+-------+
Esegui dei test con il tuo carico di lavoro per determinare se le singole istruzioni SQL possono beneficiare della funzionalità di query in parallelo. Utilizza quindi le tecniche di monitoraggio seguenti per determinare la frequenza d'uso delle query in parallelo con i carichi di lavoro reali nel tempo. Per tali carichi di lavoro, vengono applicati dei fattori supplementari come i limiti di simultaneità.
