Verificar quais declarações usam consulta paralela para Aurora MySQL
Em operações normais, você não precisa executar nenhuma ação especial para tirar vantagem da consulta paralela. Quando uma consulta atende aos requisitos essenciais de uma consulta paralela, o otimizador de consultas decide automaticamente se a consulta paralela deve ser usada para cada consulta específica.
Se você realizar experimentos em um ambiente de desenvolvimento ou teste, poderá descobrir que a consulta paralela não está sendo usada porque as tabelas são muito pequenas em termos de número de linhas ou de volume de dados geral. Os dados da tabela podem estar inteiramente em um grupo de buffers, especialmente nas tabelas que você criou recentemente para realizar os experimentos.
Ao monitorar ou ajustar a performance do cluster, decida se a consulta paralela está sendo usada nos contextos apropriados. Você pode ajustar o esquema de banco de dados, as configurações, as consultas SQL ou mesmo a topologia do cluster e as configurações de conexão do aplicativo para aproveitar esse recurso.
Para confirmar se uma consulta está usando a consulta paralela, verifique o plano da consulta (também conhecido como "plano de explicação") executando a instrução EXPLAINEXPLAIN para a consulta paralela, consulte Constructos do SQL para consulta paralela no Aurora MySQL.
O exemplo a seguir demonstra a diferença entre um plano de consulta tradicional e um plano de consulta paralela. Este plano de explicação é da Consulta 3 do teste comparativo da TPC-H. Muitos dos exemplos de consulta em toda esta seção usam as tabelas do conjunto de dados da TPC-H. Você pode obter as definições da tabela, as consultas e o programa dbgen que gera dados de amostra do site da 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;
Por padrão, a consulta pode ter um plano como o seguinte. Se você não vir a junção de hash utilizada no plano de consulta, verifique primeiro se a otimização está habilitada.
+----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+
| 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) |
+----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+
Para o Aurora MySQL versão 3, é possível habilitar a junção de hash no nível da sessão ao emitir a instrução a seguir.
SET optimizer_switch='block_nested_loop=on';
Para o Aurora MySQL 2.09 e versões posteriores, defina o parâmetro de banco de dados ou parâmetro de cluster de banco de dados aurora_disable_hash_join como 0 (desativado). Desativar aurora_disable_hash_join define o valor de optimizer_switch para hash_join=on.
Depois de ativar a junção de hash, tente executar a instrução EXPLAIN novamente. Para obter informações sobre como habilitar junções de hash e usá-las de maneira eficaz, consulte Otimizando grandes consultas de junção do Aurora MySQL com junções hash.
Com a junção de hash habilitada, mas a consulta paralela desabilitada, a consulta pode ter um plano semelhante ao seguinte, que utiliza a junção de hash, mas não utiliza a consulta paralela.
+----+-------------+----------+...+-----------+-----------------------------------------------------------------+
| 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) |
+----+-------------+----------+...+-----------+-----------------------------------------------------------------+
Com a consulta paralela habilitada, duas etapas nessa consulta podem utilizar a otimização de consulta paralela, conforme mostrado na coluna Extra na saída EXPLAIN. O processamento intensivo de E/S e da CPU nessas etapas é empurrado para a camada de armazenamento.
+----+...+--------------------------------------------------------------------------------------------------------------------------------+
| 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) |
+----+...+--------------------------------------------------------------------------------------------------------------------------------+
Para obter informações sobre como interpretar a saída de EXPLAIN para uma consulta paralela e as partes das instruções SQL nas quais a consulta paralela pode ser aplicada, consulte Constructos do SQL para consulta paralela no Aurora MySQL.
O exemplo de saída a seguir mostra os resultados da execução da consulta anterior em uma instância db.r4.2xlarge com um grupo de buffers ociosos. A execução da consulta é substancialmente mais rápida quando a consulta paralela é usada.
nota
Como as cronometragens podem depender de vários fatores relativos ao ambiente, seus resultados podem ser diferentes. Sempre faça testes de performance para confirmar suas descobertas com seu próprio ambiente, sua workload, e assim por diante.
-- 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)
Muitas das consultas de exemplo em toda esta seção usam as tabelas do conjunto de dados TPC-H, particularmente a tabela PART, que tem 20 milhões de linhas e a definição a seguir.
+---------------+---------------+------+-----+---------+-------+
| 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 | |
+---------------+---------------+------+-----+---------+-------+
Faça experiências com sua workload para ter uma noção de se as instruções SQL individuais poderão aproveitar a consulta paralela. Depois, use as técnicas de monitoramento a seguir para ajudar a verificar com que frequência a consulta paralela é usada em cargas de trabalho reais ao longo do tempo. Para cargas de trabalho reais, fatores extras como os limites de simultaneidade são aplicáveis.
