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à.
Verifica delle istruzioni che utilizzano la query parallela per Aurora My SQL
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 modificare lo schema del database, le impostazioni, le SQL query o persino la topologia del cluster e le impostazioni di connessione all'applicazione per sfruttare questa funzionalità.
Per verificare se una query utilizza una query parallela, controlla il piano di query (noto anche come «plain plan») eseguendo l'EXPLAINEXPLAINoutput di una query parallela, vedere. SQLcostrutti per interrogazioni parallele in Aurora My SQL
L'esempio seguente illustra la differenza tra un piano query tradizionale e un piano di query in parallelo. Questo piano di spiegazione è tratto dalla Query 3 del benchmark TPC -H. Molte delle query di esempio contenute in questa sezione utilizzano le tabelle del set di dati -H. TPC È possibile ottenere le definizioni delle tabelle, le interrogazioni e il dbgen programma che genera dati di esempio dal sito Web -h. TPC
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 My SQL versione 3, si attiva l'hash join a livello di sessione emettendo la seguente dichiarazione.
SET optimizer_switch='block_nested_loop=on';
Per Aurora My SQL versione 2.09 e successive, impostate il parametro DB o il parametro aurora_disable_hash_join DB cluster su 0 (off). 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 delle query Aurora SQL My join di grandi dimensioni 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 a uso intensivo e intensivo CPU di I/O per questi passaggi viene trasferita al livello di archiviazione.
+----+...+--------------------------------------------------------------------------------------------------------------------------------+
| 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'EXPLAINoutput di una query parallela e sulle parti di SQL istruzioni a cui è possibile applicare la query parallela, vedereSQLcostrutti per interrogazioni parallele in Aurora My SQL.
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)
Molte delle query di esempio contenute in questa sezione utilizzano le tabelle di questo set di dati TPC -H, in particolare la PART tabella, che ha 20 milioni di righe e la seguente definizione.
+---------------+---------------+------+-----+---------+-------+
| 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 | |
+---------------+---------------+------+-----+---------+-------+
Sperimenta con il tuo carico di lavoro per capire se SQL le singole istruzioni possono trarre vantaggio dalla query parallela. 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à.
