Visão geral de consultas paralelas Planejar um cluster de consulta paralela Criação de um cluster de consulta paralela Habilitar e desabilitar a consulta paralela Atualizar um cluster de consulta paralela Ajuste de performance Criação de objetos de esquema Verificar o uso da consulta paralela Monitoramento Consulta paralela e construções SQL

Como trabalhar com a consulta paralela do Amazon Aurora MySQL

Este tópico descreve a performance de consultas paralelas do Amazon Aurora edição compatível com MySQL. Este recurso usa um caminho de processamento especial para determinadas consultas com muitos dados, aproveitando a arquitetura de armazenamento compartilhada do Aurora. As consultas paralelas funcionam melhor com clusters de bancos de dados Aurora MySQL que têm tabelas com milhões de linhas e consultas analíticas que levam minutos ou horas para concluir.

Sumário

Visão geral de consultas paralelas do Aurora MySQL

A consulta paralela do Aurora MySQL é uma otimização que paraleliza uma parte da E/S e da computação envolvidas nas consultas de processamento com muitos dados. O trabalho que é paralelizado inclui linhas de recuperação de armazenamento, extração de valores de colunas e determinação de quais linhas correspondem às condições na cláusula WHERE e em cláusulas de junção. O trabalho com muitos dados é delegado (em termos de otimização de banco de dados, empurrado) para vários nós na camada de armazenamento distribuído do Aurora. Sem as consultas paralelas, cada consulta traz todos os dados de varredura para um nó único dentro do cluster do Aurora MySQL (o nó de cabeçalho) e realiza todo o processamento de consultas lá.

dica

O mecanismo de banco de dados PostgreSQL também tem um recurso denominado “consulta paralela”. Esse recurso não está relacionado à consulta paralela do Aurora.

Quando o recurso de consulta paralela está habilitado, o mecanismo do Aurora MySQL determina automaticamente quando as consultas podem se beneficiar, sem exigir alterações de SQL como avisos ou atributos de tabela. Nas seções a seguir, você encontrará uma explicação sobre quando uma consulta paralela é aplicada a uma consulta. Você também descobrirá como garantir que a consulta paralela seja aplicada onde ela pode oferecer o maior benefício.

nota

A otimização de consultas paralelas oferece o maior benefício para consultas de longa duração que levam minutos ou horas para serem concluídas. Geralmente, o Aurora MySQL não executa a otimização de consulta paralela para consultas pouco dispendiosas. Normalmente, ele também não executa otimização de consultas paralelas se outra técnica de otimização faz mais sentido, como o armazenamento em cache de consultas, armazenamento em cache de grupos de buffer ou pesquisas de índice. Se o recurso de consulta paralela não estiver sendo usado quando você espera, consulte Verificar quais instruções usam a consulta paralela.

Benefícios

Com a consulta paralela, você pode executar consultas analíticas com uso intensivo de dados em tabelas do Aurora MySQL. Em muitos casos, você pode obter uma melhoria de performance de ordem de grandeza em relação à divisão tradicional de trabalho para processamento de consultas.

Os benefícios da consulta paralela incluem o seguinte:

Melhor performance de E/S devido ao paralelismo de solicitações de leitura físicas entre vários nós de armazenamento.
Menor tráfego de rede. O Aurora não transmite páginas inteiras de dados dos nós de armazenamento até o nó de cabeçalho para depois filtrar as linhas e colunas desnecessárias. Em vez disso, o Aurora transmite tuplas compactas que contêm somente os valores das colunas necessários para o conjunto de resultados.
Uso reduzido de CPU no nó de cabeçalho, pois o processamento da função, a filtragem de linhas e a projeção de colunas para a cláusula WHERE são delegadas (ou “empurradas”).
Pressão reduzida da memória no grupo de buffers. As páginas processadas pela consulta paralela não são adicionadas ao grupo de buffer. Essa abordagem reduz a chance de uma verificação intensiva de dados despejar dados usados com frequência do grupo de buffer.
Possível redução da duplicação de dados em seu pipeline de extração, transformação e carga (ETL), ao tornar mais prática a realização de consultas analíticas de longa execução em dados existentes.

Arquitetura

O recurso de consulta paralela usa os princípios de arquitetura mais importantes do Aurora MySQL: desacoplamento do mecanismo de banco de dados do subsistema de armazenamento e redução do tráfego de rede com a simplificação dos protocolos de comunicação. O Aurora MySQL usa essas técnicas para acelerar operações de gravação intensiva, como processamento de log de refazimento. A consulta paralela aplica os mesmos princípios nas operações de leitura.

nota

A arquitetura da consulta paralela do Aurora MySQL é diferente da arquitetura de outros recursos semelhantes em outros sistemas de banco de dados. A consulta paralela do Aurora MySQL não envolve o multiprocessamento simétrico (SMP) e, portanto, não depende da capacidade da CPU do servidor de banco de dados. O processamento paralelo ocorre na camada de armazenamento, de forma independente do servidor do Aurora MySQL que funciona como o coordenador de consultas.

Por padrão, sem a consulta paralela, o processamento de uma consulta do Aurora envolve a transmissão de dados brutos para um nó único dentro do cluster do Aurora (o nó do cabeçalho). Depois, o Aurora executa todo o processamento adicional para essa consulta em um único thread desse nó único. Com a consulta paralela, a maior parte do trabalho intensivo de E/S e da CPU é delegado aos nós na camada de armazenamento. Somente as linhas compactas do conjunto de resultados são transmitidas de volta ao nó de cabeçalho, com as linhas já filtradas e os valores das colunas já extraídos e transformados. O benefício com relação à performance vem com a redução no tráfego da rede, a redução do uso de CPU no nó de cabeçalho e o paralelismo da E/S entre os nós de armazenamento. A quantidade de E/S, filtragem e projeção que são paralelizados independe do número de instâncias de banco de dados no cluster do Aurora que executa a consulta.

Pré-requisitos

O uso de todos os recursos da consulta paralela exige um cluster de bancos de dados do Aurora MySQL que esteja executando a versão 2.09 ou posterior. Se você já tiver um cluster que deseja utilizar com consultas paralelas, será possível atualizá-lo para uma versão compatível e habilitar consultas paralelas posteriormente. Nesse caso, siga o procedimento de atualização em Considerações sobre atualização para consultas paralelas porque os nomes de definição da configuração e os valores padrão são diferentes nessas versões mais recentes.

As instâncias de banco de dados no cluster devem usar as classes de instância db.r*.

A otimização da junção de hash deve estar ativada para o cluster. Para saber como, consulte Habilitar a junção de hash para clusters de consulta paralela.

Para personalizar parâmetros como aurora_parallel_query e aurora_disable_hash_join, é necessário ter um grupo de parâmetros personalizado usado com o cluster. É possível especificar esses parâmetros individualmente para cada instância de banco de dados usando um grupo de parâmetros de banco de dados. No entanto, recomendamos que você os especifique em um grupo de parâmetros do cluster de banco de dados. Dessa forma, todas as instâncias de banco de dados no cluster herdam as mesmas configurações para esses parâmetros.

Limitações

Os seguintes limitações se aplicam ao recurso de consulta paralela:

A consulta paralela não é compatível com a configuração de armazenamento do cluster de banco de dados do Aurora I/O-Optimized.
Não é possível usar a consulta paralela com as classes de instância db.t2 ou db.t3. Essa limitação se aplica mesmo se você solicitar a consulta paralela usando a variável de sessão aurora_pq_force.
A consulta paralela não se aplica a tabelas que usam os formatos de linha COMPRESSED ou REDUNDANT. Use os formatos de linha COMPACT ou DYNAMIC para tabelas que você planeja usar com a consulta paralela.
O Aurora usa um algoritmo baseado em custo para determinar se deve usar o mecanismo de consulta paralela para cada instrução SQL. Usar certas construções de SQL em uma instrução pode impedir a consulta paralela ou torná-la improvável para essa instrução. Para obter informações sobre a compatibilidade de construções de SQL com a consulta paralela, consulte Como a consulta paralela funciona com construções SQL.
Cada instância de bancos de dados Aurora só pode executar um determinado número de sessões de consultas paralelas de cada vez. Se uma consulta tiver várias partes que usam a consulta paralela, como subconsultas, junções ou operadores UNION, essas fases serão executadas em sequência. A instrução só conta com uma sessão de consulta paralela única de cada vez. Você pode monitorar o número de sessões ativas usando as variáveis de status de consulta paralela. Você pode verificar o limite de sessões simultâneas para uma determinada instância de banco de dados consultando a variável de status Aurora_pq_max_concurrent_requests.
A consulta paralela está disponível em todas as regiões da AWS que oferecem suporte ao Aurora. Para a maioria das regiões da AWS, a versão mínima necessária do Aurora MySQL para usar a consulta paralela é a 2.09.
A consulta paralela foi projetada para melhorar a performance de consultas com uso intenso de dados. Ela não foi projetada para consultas leves.
Recomendamos que você use nós de leitor para instruções SELECT, especialmente para as que fazem uso intenso de dados.

Os custos de E/S com a consulta paralela

Se seu cluster do Aurora MySQL usar consulta paralela, você poderá ver um aumento nos valores de VolumeReadIOPS. As consultas paralelas não usam o grupo de buffers. Assim, embora as consultas sejam rápidas, esse processamento otimizado pode resultar em aumento nas operações de leitura e nas cobranças associadas.

Os custos de E/S de consulta paralela para uma consulta são medidos na camada de armazenamento e serão iguais ou maiores com a consulta paralela ativada. Seu benefício é a melhoria na performance da consulta. Os custos de E/S de consultas paralelas podem aumentar por dois motivos:

Mesmo que alguns dos dados em uma tabela estejam no grupo de buffers, a consulta paralela exige que todos os dados sejam escaneados na camada de armazenamento, gerando custos de E/S.
A execução de uma consulta paralela não aquece o grupo de buffers. Por isso, execuções consecutivas da mesma consulta paralela contribuem para o custo total de E/S.

Planejar um cluster de consulta paralela

A ação de planejar um cluster de banco de dados com consulta paralela habilitada requer algumas escolhas. Isso inclui a realização de etapas de configuração (criar ou restaurar um cluster do Aurora MySQL completo) e a decisão da extensão da habilitação da consulta paralela no cluster de banco de dados.

Considere o seguinte como parte do planejamento:

Se você usar o Aurora MySQL compatível com o MySQL 5.7, escolha o Aurora MySQL 2.09 ou posterior. Nesse caso, você sempre cria um cluster provisionado. Em seguida, habilite a consulta paralela utilizando o parâmetro aurora_parallel_query.

Se você tiver um cluster do Aurora MySQL que esteja executando a versão 2.09 ou posterior, não precisará criar outro cluster para usar a consulta paralela. É possível associar o cluster, ou instâncias de banco de dados específicas no cluster, a um grupo de parâmetros que tenha o parâmetro aurora_parallel_query habilitado. Ao fazer isso, é possível reduzir o tempo e o esforço para configurar os dados relevantes a serem usados com a consulta paralela.
Planeje todas as tabelas grandes que você precisa reorganizar para que possa usar a consulta paralela ao acessá-las. Talvez seja necessário criar versões de algumas tabelas grandes nas quais a consulta paralela é útil. Por exemplo, talvez seja necessário remover índices de pesquisa de texto completo. Para obter mais detalhes, consulte Criar objetos de esquema que aproveitem a consulta paralela.

Verificar se a versão do Aurora MySQL é compatível com a consulta paralela

Para verificar quais versões do Aurora MySQL são compatíveis com clusters de consulta paralela, use o comando describe-db-engine-versions da AWS CLI e verifique o valor do campo SupportsParallelQuery. O exemplo de código a seguir mostra como verificar quais combinações estão disponíveis para clusters de consulta paralela em uma região da AWS especificada. Especifique a string completa do parâmetro --query em uma única linha.


aws rds describe-db-engine-versions --region us-east-1 --engine aurora-mysql \
--query '*[]|[?SupportsParallelQuery == `true`].[EngineVersion]' --output text

Os comandos anteriores produzem uma saída semelhante à seguinte. A saída pode variar, dependendo de quais versões do Aurora MySQL estão disponíveis na região da AWS especificada.


5.7.mysql_aurora.2.11.1
8.0.mysql_aurora.3.01.0
8.0.mysql_aurora.3.01.1
8.0.mysql_aurora.3.02.0
8.0.mysql_aurora.3.02.1
8.0.mysql_aurora.3.02.2
8.0.mysql_aurora.3.03.0

Após começar a usar a consulta paralela com um cluster, você pode monitorar a performance e remover obstáculos ao uso da consulta paralela. Para obter essas instruções, consulte Ajuste de performance da consulta paralela.

Criação de cluster de banco de dados que funciona com consulta paralela

Para criar um cluster do Aurora MySQL com consulta paralela, adicionar novas instâncias a ele ou executar outras operações administrativas, use as mesmas técnicas do AWS Management Console e da AWS CLI usadas com outros clusters do Aurora MySQL. Você pode criar um cluster novo para trabalhar com a consulta paralela. Também é possível criar um cluster de banco de dados para trabalhar com a consulta paralela fazendo a restauração de um snapshot de um cluster de bancos de dados Aurora compatível com o MySQL. Se você não tem familiaridade com o processo de criação de um cluster novo do Aurora MySQL, encontrará as informações básicas e os pré-requisitos em Criar um cluster de bancos de dados do Amazon Aurora.

Ao escolher uma versão do mecanismo Aurora MySQL, recomendamos que escolha a versão mais recente disponível. No momento, o Aurora MySQL 2.09 e versões posteriores são compatíveis com consultas paralelas. Você tem maior flexibilidade para ativar e desativar a consulta paralela, ou usar consulta paralela com clusters existentes, se usar o Aurora MySQL 2.09 ou posterior.

Ao criar um cluster novo ou restaurar um snapshot, use as mesmas técnicas que você usa com outros clusters do Aurora MySQL para adicionar novas instâncias de banco de dados.

Criar um cluster de consulta paralela com o console

Você pode criar um novo cluster de consulta paralela com o console, conforme descrito a seguir.

Para criar um cluster de consulta paralela com o AWS Management Console

Siga o procedimento geral do AWS Management Console em Criar um cluster de bancos de dados do Amazon Aurora.
Na tela Select engine (Selecionar mecanismo), selecione o Aurora MySQL.

Em Versão do mecanismo, escolha Aurora MySQL 2.09 ou posterior. Com essas versões, você tem o menor número de limitações no uso da consulta paralela. Essas versões também têm a maior flexibilidade para ativar ou desativar a consulta paralela a qualquer momento.

Se não for prático usar uma versão recente do Aurora MySQL para esse cluster, selecione Show versions that support the parallel query feature (Mostrar versões que oferecem suporte ao recurso de consulta paralela). Isso filtra o menu Version (Versão) para mostrar apenas as versões específicas do Aurora MySQL que são compatíveis com a consulta paralela.
Em Configuração adicional, escolha um grupo de parâmetros criado para o Grupo de parâmetros do cluster de banco de dados. O uso de um grupo de parâmetros personalizado é exigido para o Aurora MySQL 2.09 ou posteriores. No grupo de parâmetros do cluster de banco de dados, especifique as configurações de parâmetro aurora_parallel_query=ON e aurora_disable_hash_join=OFF. Isso habilita a consulta paralela para o cluster e possibilita a otimização de junções de hash que funciona em combinação com a consulta paralela.

Para verificar se um cluster novo pode usar a consulta paralela

Crie um cluster usando a técnica anterior.

(Para o Aurora MySQL versões 2 ou 3) Verifique se a definição da configuração aurora_parallel_query é true.


mysql> select @@aurora_parallel_query;
+-------------------------+
| @@aurora_parallel_query |
+-------------------------+
|                       1 |
+-------------------------+

(Para o Aurora MySQL versão 2) Verifique se a configuração aurora_disable_hash_join está definia como false.


mysql> select @@aurora_disable_hash_join;
+----------------------------+
| @@aurora_disable_hash_join |
+----------------------------+
|                          0 |
+----------------------------+

Com algumas tabelas grandes e consultas com uso intenso de dados, confirme nos planos de consulta se algumas de suas consultas estão usando a otimização de consulta paralela. Para fazer isso, siga o procedimento em Verificar quais instruções usam a consulta paralela.

Criar um cluster de consulta paralela com a CLI

Você pode criar um novo cluster de consulta paralela com a CLI, conforme descrito a seguir.

Para criar um cluster de consulta paralela com o AWS CLI

(Opcional) Verifique quais versões do Aurora MySQL são compatíveis com clusters de consulta paralela. Para fazer isso, use o comando describe-db-engine-versions e verifique o valor do campo SupportsParallelQuery. Para ver um exemplo, consulte Verificar se a versão do Aurora MySQL é compatível com a consulta paralela.
(Opcional) Crie um grupo de parâmetros do cluster de banco de dados personalizado com as configurações aurora_parallel_query=ON e aurora_disable_hash_join=OFF. Use comandos como os seguintes.
```
aws rds create-db-cluster-parameter-group --db-parameter-group-family aurora-mysql5.7 --db-cluster-parameter-group-name pq-enabled-57-compatible
aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name pq-enabled-57-compatible \
  --parameters ParameterName=aurora_parallel_query,ParameterValue=ON,ApplyMethod=pending-reboot
aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name pq-enabled-57-compatible \
  --parameters ParameterName=aurora_disable_hash_join,ParameterValue=OFF,ApplyMethod=pending-reboot
```
Se você executar essa etapa, especifique a opção --db-cluster-parameter-group-name my_cluster_parameter_group na instrução create-db-cluster subsequente. Substitua o nome do seu próprio grupo de parâmetros. Se você omitir essa etapa, crie o grupo de parâmetros e associe-o ao cluster posteriormente, conforme descrito em Habilitar e desabilitar a consulta paralela.
Siga o procedimento geral do AWS CLI em Criar um cluster de bancos de dados do Amazon Aurora.
Especifique o seguinte conjunto de opções:
- Para a opção --engine, use aurora-mysql. Esses valores produzem clusters de consulta paralela compatíveis com o MySQL 5.7 ou 8.0.
- Para a opção --db-cluster-parameter-group-name, especifique o nome de um grupo de parâmetros do cluster de banco de dados que você criou e para o qual especificou o valor do parâmetro aurora_parallel_query=ON. Se você omitir essa opção, poderá criar o cluster com um grupo de parâmetros padrão e modificá-lo posteriormente para usar esse grupo de parâmetros personalizado.
- Para a opção --engine-version, use uma versão do Aurora MySQL compatível com a consulta paralela. Use o procedimento de Planejar um cluster de consulta paralela para obter uma lista de versões, se necessário. Use pelo menos a versão 2.09.0. Essas versões e todas as posteriores contêm melhorias substanciais para consulta paralela.
  
  O exemplo de código a seguir mostra como fazer isso. Substitua seu próprio valor para cada uma das variáveis de ambiente, como $CLUSTER_ID. Este exemplo também especifica a opção --manage-master-user-password para gerar a senha mestra do usuário e gerenciá-la no Secrets Manager. Para ter mais informações, consulte Gerenciamento de senhas com Amazon Aurora e AWS Secrets Manager. Como alternativa, você pode usar a opção --master-password para especificar e gerenciar a senha por conta própria.
```
aws rds create-db-cluster --db-cluster-identifier $CLUSTER_ID \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --master-username $MASTER_USER_ID --manage-master-user-password \
  --db-cluster-parameter-group-name $CUSTOM_CLUSTER_PARAM_GROUP

aws rds create-db-instance --db-instance-identifier ${INSTANCE_ID}-1 \
  --engine same_value_as_in_create_cluster_command \
  --db-cluster-identifier $CLUSTER_ID --db-instance-class $INSTANCE_CLASS
```
Verifique se um cluster que você criou ou restaurou tem o recurso de consulta paralela disponível.

Verifique se a configuração aurora_parallel_query existe. Se essa configuração tiver o valor 1, a consulta paralela estará pronta para ser usada. Se essa configuração tiver o valor 0, defina-a como 1 para poder usar a consulta paralela. De qualquer forma, o cluster é capaz de executar consultas paralelas.
```
mysql> select @@aurora_parallel_query;
+------------------------+
| @@aurora_parallel_query|
+------------------------+
|                      1 |
+------------------------+
```

Para restaurar um snapshot em um cluster de consulta paralela com o AWS CLI

Verifique quais versões do Aurora MySQL são compatíveis com clusters de consulta paralela. Para fazer isso, use o comando describe-db-engine-versions e verifique o valor do campo SupportsParallelQuery. Para ver um exemplo, consulte Verificar se a versão do Aurora MySQL é compatível com a consulta paralela. Decida qual versão usar para o cluster restaurado. Escolha o Aurora MySQL 2.09.0 ou posterior para um cluster compatível com o MySQL 5.7.
Encontre um snapshot de cluster compatível com o Aurora MySQL.

Siga o procedimento geral do AWS CLI em Restauração de um snapshot de um cluster de banco de dados.


aws rds restore-db-cluster-from-snapshot \
  --db-cluster-identifier mynewdbcluster \
  --snapshot-identifier mydbclustersnapshot \
  --engine aurora-mysql

Verifique se um cluster que você criou ou restaurou tem o recurso de consulta paralela disponível. Use o mesmo procedimento de verificação descrito em Criar um cluster de consulta paralela com a CLI.

Habilitar e desabilitar a consulta paralela

Quando a consulta paralela está habilitada, o Aurora MySQL determina se deve utilizá-la em tempo de execução para cada consulta. No caso de junções, uniões, subconsultas etc., o Aurora MySQL determinará se usará a consulta paralela em tempo de execução para cada bloco de consulta. Para obter mais detalhes, consulte Verificar quais instruções usam a consulta paralela e Como a consulta paralela funciona com construções SQL.

É possível habilitar e desabilitar a consulta paralela dinamicamente no nível global e da sessão para uma instância de banco de dados utilizando a opção aurora_parallel_query. Você pode alterar a configuração aurora_parallel_query no grupo de clusters de banco de dados para ativar ou desativar a consulta paralela por padrão.


mysql> select @@aurora_parallel_query;
+------------------------+
| @@aurora_parallel_query|
+------------------------+
|                      1 |
+------------------------+

Para ativar ou desativar o parâmetro aurora_parallel_query no nível da sessão, use os métodos padrão para alterar a definição da configuração do cliente. Por exemplo, você pode fazer isso pela linha de comando mysql ou em uma aplicação JDBC ou ODBC. O comando no cliente MySQL padrão é set session aurora_parallel_query = {'ON'/'OFF'}. Você também pode adicionar o parâmetro de nível de sessão à configuração JDBC ou dentro do código da sua aplicação para habilitar ou desabilitar a consulta paralela dinamicamente.

É possível alterar permanentemente a configuração do parâmetro aurora_parallel_query, seja para uma instância de banco de dados específica ou para todo o cluster. Se você especificar o valor do parâmetro em um grupo de parâmetros de banco de dados, esse valor só será aplicado a uma instância de banco de dados específica no cluster. Se você especificar o valor do parâmetro em um grupo de parâmetros do cluster de banco de dados, todas as instâncias de banco de dados no cluster herdarão a mesma configuração. Para ativar ou desativar o parâmetro aurora_parallel_query, utilize as técnicas usadas com grupos de parâmetros, conforme descrito em Trabalhar com grupos de parâmetros. Siga estas etapas:

Crie um grupo de parâmetros de cluster personalizado (recomendado) ou um grupo de parâmetros de banco de dados personalizado.
Nesse grupo de parâmetros, atualize parallel_query para o valor desejado.
Dependendo se você criou um grupo de parâmetros do cluster de banco de dados ou um grupo de parâmetros de banco de dados, anexe o grupo de parâmetros ao cluster do Aurora ou às instâncias de banco de dados específicas nas quais você planeja usar o recurso de consulta paralela.

dica
Como aurora_parallel_query é um parâmetro dinâmico, não é necessário reiniciar o cluster depois de alterar essa configuração. No entanto, todas as conexões que estiverem usando consulta paralela antes de alternar a opção continuarão a fazê-lo até que a conexão seja fechada ou a instância seja reinicializada.

Você pode modificar o parâmetro da consulta paralela usando a operação da API ModifyDBClusterParameterGroup ou ModifyDBParameterGroup no AWS Management Console.

Habilitar a junção de hash para clusters de consulta paralela

A consulta paralela é normalmente usada para tipos de consultas que consomem muitos recursos e que se beneficiam da otimização de junções de hash. Portanto, é útil garantir que as junções de hash estejam habilitadas para os clusters nos quais você pretende utilizar a consulta paralela. 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.

Habilitar e desabilitar a consulta paralela com o uso do console

É possível habilitar ou desabilitar a consulta paralela no nível da instância de banco de dados ou do cluster de banco de dados trabalhando com grupos de parâmetros.

Para habilitar ou desabilitar a consulta paralela para um cluster de banco de dados com o AWS Management Console

Crie um parameter group personalizado conforme descrito em Trabalhar com grupos de parâmetros.
Atualize aurora_parallel_query para 1 (ativada) ou 0 (desativada). Em clusters nos quais o recurso de consulta paralela está disponível, aurora_parallel_query está desabilitado por padrão.
Se você usar um grupo de parâmetros de cluster personalizado, anexe-o ao cluster de bancos de dados Aurora onde planeja usar o recurso de consulta paralela. Se você usar um grupo de parâmetros de banco de dados personalizado, anexe-o a uma ou mais instâncias de banco de dados no cluster. Recomendamos o uso de um grupo de parâmetros de cluster. Isso garante que todas as instâncias de banco de dados no cluster tenham as mesmas configurações para consulta paralela e recursos associados, como a junção de hash.

Habilitar e desabilitar a consulta paralela com o uso da CLI

Você pode modificar o parâmetro de consulta paralela usando o comando modify-db-cluster-parameter-group ou modify-db-parameter-group. Escolha o comando apropriado dependendo se você especificar o valor de aurora_parallel_query por meio de um grupo de parâmetros de cluster de banco de dados ou de um grupo de parâmetros de banco de dados.

Para habilitar ou desabilitar a consulta paralela para um cluster de banco de dados com a CLI

Modifique o parâmetro de consulta paralela usando o comando modify-db-cluster-parameter-group. Use um comando como o seguinte. Substitua o nome apropriado para o seu próprio grupo de parâmetros personalizado. Substitua ON ou OFF da parte ParameterValue da opção --parameters.



$ aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name cluster_param_group_name \
  --parameters ParameterName=aurora_parallel_query,ParameterValue=ON,ApplyMethod=pending-reboot
{
    "DBClusterParameterGroupName": "cluster_param_group_name"
}

aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name cluster_param_group_name \
  --parameters ParameterName=aurora_pq,ParameterValue=ON,ApplyMethod=pending-reboot

Você também pode habilitar ou desabilitar a consulta no nível de sessão, por exemplo, por meio da linha de comando mysql ou dentro de uma aplicação JDBC ou ODBC. Para fazer isso, use os métodos padrão para alterar uma configuração de cliente. Por exemplo, o comando no cliente MySQL padrão é set session aurora_parallel_query = {'ON'/'OFF'} para o Aurora MySQL.

Você também pode adicionar o parâmetro de nível de sessão à configuração JDBC ou dentro do código da sua aplicação para habilitar ou desabilitar a consulta paralela dinamicamente.

Substituir o otimizador de consulta paralela

Você pode usar a variável de sessão aurora_pq_force para substituir o otimizador de consulta paralela e solicitar uma consulta paralela para cada consulta. Recomendamos que você faça isso apenas para fins de teste. O exemplo a seguir mostra como usar aurora_pq_force em uma sessão.


set SESSION aurora_parallel_query = ON;
set SESSION aurora_pq_force = ON;

Para desativar a substituição, faça o seguinte:


set SESSION aurora_pq_force = OFF;

Considerações sobre atualização para consultas paralelas

Dependendo das versões original e de destino ao fazer o upgrade de um cluster de consulta paralela, você pode perceber melhorias nos tipos de consultas que a consulta paralela é capaz de otimizar. Você também pode descobrir que não é necessário especificar um parâmetro de modo de mecanismo especial para a consulta paralela. As seções a seguir explicam as considerações ao fazer upgrade de um cluster com a consulta paralela habilitada.

Fazer upgrade de clusters de consulta paralela para o Aurora MySQL versão 3

Várias instruções, cláusulas e tipos de dados SQL incluem suporte novo ou avançado para consulta paralela começando com o Aurora MySQL versão 3. Ao fazer upgrade de uma versão anterior à versão 3, verifique se consultas adicionais podem se beneficiar com otimizações de consultas paralelas. Para obter informações sobre essas melhorias de consulta paralela, consulte Tipos de dados de coluna,Tabelas particionadas e Funções agregadas, cláusulas GROUP BY e cláusulas HAVING..

Se estiver fazendo upgrade de um cluster de consulta paralela do Aurora MySQL 2.08 ou versão inferior, informe-se também sobre as mudanças em como habilitar a consulta paralela. Para isso, leia Fazer upgrade para o Aurora MySQL 2.09 e versões posteriores.

No Aurora MySQL versão 3, a otimização de junções de hash está habilitada por padrão. A opção de configuração aurora_disable_hash_join de versões anteriores não é utilizada.

Fazer upgrade para o Aurora MySQL 2.09 e versões posteriores

No Aurora MySQL versão 2.09 e posteriores, a consulta paralela funciona para clusters provisionados e não requer o parâmetro parallelquery do modo de mecanismo. Assim, você não precisa criar um cluster nem restaurar de um snapshot existente para usar a consulta paralela com essas versões. Você pode usar os procedimentos de atualização descritos em Atualizando a versão secundária ou o nível de patch de um cluster de banco de dados de Aurora MySQL a fim de atualizar o cluster para essa versão. Você pode atualizar um cluster mais antigo, independentemente de se tratar de um cluster de consulta paralela ou de um cluster provisionado. Para reduzir o número de opções no menu Engine version (Versão do mecanismo) você pode selecionar Show versions that support the parallel query feature (Mostrar versões que oferecem suporte ao recurso de consulta paralela) para filtrar as entradas nesse menu. Depois, escolha o Aurora MySQL 2.09 ou posteriores.

Depois de fazer upgrade de um cluster de consulta paralela anterior para o Aurora MySQL 2.09 ou versão posterior, habilite a consulta paralela no cluster atualizado. A consulta paralela é desativada por padrão nessas versões e o procedimento para habilitá-la é diferente. A otimização de junções de hash também está desabilitada por padrão e deve ser habilitada separadamente. Por isso, certifique-se de habilitar essas configurações novamente após o upgrade. Para obter instruções sobre como fazer isso, consulte Habilitar e desabilitar a consulta paralela e Habilitar a junção de hash para clusters de consulta paralela.

Em particular, você habilita consulta paralela utilizando os parâmetros de configuração aurora_parallel_query=ON e aurora_disable_hash_join=OFF em vez de aurora_pq_supported e aurora_pq. Os parâmetros aurora_pq_supported e aurora_pq é compatível com atualizações nas versões mais recentes do Aurora MySQL.

No cluster atualizado, o atributo EngineMode tem o valor provisioned em vez de parallelquery. Para verificar se a consulta paralela está disponível para uma versão de mecanismo especificada, agora você confere o valor do campo SupportsParallelQuery na saída do comando describe-db-engine-versions da AWS CLI. Em versões anteriores do Aurora MySQL, você verificou a presença de parallelquery na lista SupportedEngineModes.

Depois de fazer upgrade para o Aurora MySQL 2.09 ou versão posterior, você poderá aproveitar os recursos a seguir. Esses recursos não estão disponíveis para clusters de consulta paralela que executam versões mais antigas do Aurora MySQL.

Performance Insights. Para ter mais informações, consulte Monitorar a carga de banco de dados com o Performance Insights no Amazon Aurora.
Retroceder. Para ter mais informações, consulte Retroceder um cluster de banco de dados Aurora.
Interromper e iniciar o cluster. Para ter mais informações, consulte Interromper e iniciar um cluster de banco de dados do Amazon Aurora.

Ajuste de performance da consulta paralela

Para gerenciar a performance de uma workload com consulta paralela, verifique se a consulta paralela é usada em consultas em que a otimização é mais útil.

Para isso, você pode fazer o seguinte:

As tabelas maiores devem ser compatíveis com a consulta paralela. Você pode alterar as propriedades da tabela ou recriar algumas tabelas para que as consultas delas possam aproveitar a otimização da consulta paralela. Para saber como, consulte Criar objetos de esquema que aproveitem a consulta paralela.
Monitore quais são as consultas que usam a consulta paralela. Para saber como, consulte Monitoramento de consulta paralela.
Verifique se a consulta paralela está sendo usada para as consultas mais intensas e de longa execução e com o nível certo de simultaneidade para a workload. Para saber como, consulte Verificar quais instruções usam a consulta paralela.
Adapte seu código SQL para permitir que a consulta paralela seja aplicada às consultas esperadas. Para saber como, consulte Como a consulta paralela funciona com construções SQL.

Criar objetos de esquema que aproveitem a consulta paralela

Antes de criar ou modificar tabelas que você planeja usar para consulta paralela, conheça os requisitos descritos em Pré-requisitos e Limitações.

Como a consulta paralela exige que as tabelas usem a configuração ROW_FORMAT=Compact ou ROW_FORMAT=Dynamic, verifique as definições de configurações do Aurora para saber se houve alguma alteração na opção de configuração INNODB_FILE_FORMAT. Execute a instrução SHOW TABLE STATUS para confirmar o formato da linha de todas as tabelas do banco de dados.

Antes de alterar seu esquema para permitir que a consulta paralela funcione com mais tabelas, não deixe de fazer testes. Os testes devem confirmar se a consulta paralela resulta em um aumento líquido na performance dessas tabelas. Além disso, certifique-se de que os requisitos do esquema para a consulta paralela são compatíveis com as suas metas.

Por exemplo, antes de mudar de ROW_FORMAT=Compressed para ROW_FORMAT=Compact ou ROW_FORMAT=Dynamic, teste a performance das cargas de trabalho das tabelas originais e novas. Considere também outros efeitos possíveis, como o aumento do volume de dados.

Verificar quais instruções usam a consulta paralela

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 EXPLAIN. Para ver exemplos de como as instruções, cláusulas e expressões SQL afetam a saída de EXPLAIN para a consulta paralela, consulte Como a consulta paralela funciona com construções SQL.

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 Como a consulta paralela funciona com construções SQL.

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.

Monitoramento de consulta paralela

Além das métricas do Amazon CloudWatch descritas em Visualizar métricas no console do Amazon RDS, o Aurora fornece outras variáveis de status globais. Você pode usar essas variáveis de status global para ajudar a monitorar a execução de consultas paralelas. Elas podem fornecer informações sobre por que o otimizador pode usar ou não a consulta paralela em determinada situação. Para acessar essas variáveis, use o comando SHOW GLOBAL STATUS. Veja também essas variáveis listadas a seguir.

Uma sessão de consulta paralela não é necessariamente um mapeamento de um para um com as consultas executadas pelo banco de dados. Por exemplo, suponha que o plano de consulta tem duas etapas que usam consulta paralela. Neste caso, a consulta envolve duas sessões paralelas e os contadores das tentativas de solicitações, e as solicitações bem-sucedidas são acrescidas de dois.

Quando você experimenta a consulta paralela executando as instruções EXPLAIN, espere ver aumentos nos contadores designados como "não escolhidos" mesmo que, na realidade, as consultas não estejam sendo executadas. Quando você trabalhar com uma consulta paralela na produção, poderá verificar se os contadores "não escolhidos" são acrescidos com maior rapidez do que o esperado. Nesse caso, você pode ajustar para que a paralela seja executada para as consultas que deseja. Para fazer isso, é possível alterar as configurações do cluster, a combinação de consultas, as instâncias de banco de dados nas quais a consulta paralela está habilitada e assim por diante.

Esse contadores são rastreados no nível da instância de banco de dados. Quando você se conectar a um endpoint diferente, poderá ver métricas diferentes porque cada instância de banco de dados executa seu conjunto próprio de consultas paralelas. Você também poderá ver métricas diferentes quando o endpoint de leitura se conectar a uma instância de banco de dados diferente para cada sessão.

Nome	Descrição
`Aurora_pq_bytes_returned`	O número de bytes de estruturas de dados de tupla transmitidos para o nó de cabeçalho durante as consultas paralelas. Divida por 16.384 para comparar com `Aurora_pq_pages_pushed_down`.
`Aurora_pq_max_concurrent_requests`	O número máximo de sessões de consulta paralela que podem ser executadas simultaneamente nesta instância de bancos de dados Aurora. Esse é um número fixo, que depende da classe da instância de banco de dados da AWS.
`Aurora_pq_pages_pushed_down`	O número de páginas de dados (cada uma com um tamanho fixo de 16 KiB) em que a consulta paralela evitou uma transmissão de rede para o nó de cabeçalho.
`Aurora_pq_request_attempted`	O número de sessões de consultas paralelas solicitadas. Esse valor pode representar mais de uma sessão por consulta, dependendo dos elementos SQL, como subconsultas e junções.
`Aurora_pq_request_executed`	O número de sessões de consultas paralelas executadas com êxito.
`Aurora_pq_request_failed`	O número de sessões de consultas paralelas que retornaram um erro para o cliente. Em alguns casos, uma solicitação por uma consulta paralela pode falhar, por exemplo, devido a um problema na camada de armazenamento. Nesses casos, a parte da consulta que falhou é reprocessada usando um mecanismo de consulta não paralelo. Se a consulta reprocessada também falhar, será retornado um erro para o cliente e o contador será incrementado.
`Aurora_pq_request_in_progress`	O número de sessões de consultas paralelas em andamento no momento. Esse número se aplica à instância de bancos de dados Aurora em particular à qual você está conectado, e não a todo o cluster de bancos de dados Aurora. Para saber se uma instância de banco de dados está próxima do limite de simultaneidade, compare este valor a `Aurora_pq_max_concurrent_requests`.
`Aurora_pq_request_not_chosen`	O número de vezes em que a consulta paralela não foi escolhida para atender uma consulta. Este valor é a soma de vários outros contadores mais granulares. Uma declaração `EXPLAIN` pode incrementar esse contador mesmo que a consulta não seja realmente executada.
`Aurora_pq_request_not_chosen_below_min_rows`	O número de vezes em que a consulta paralela não foi escolhida devido ao número de linhas na tabela. Uma declaração `EXPLAIN` pode incrementar esse contador mesmo que a consulta não seja realmente executada.
`Aurora_pq_request_not_chosen_column_bit`	O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela devido a um tipo de dados sem suporte na lista de colunas projetadas.
`Aurora_pq_request_not_chosen_column_geometry`	O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a tabela tem colunas com o tipo de dados `GEOMETRY`. Para saber mais sobre as versões do Aurora MySQL que removem essa limitação, consulte Fazer upgrade de clusters de consulta paralela para o Aurora MySQL versão 3.
`Aurora_pq_request_not_chosen_column_lob`	O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a tabela inclui colunas com um tipo de dados `LOB` ou colunas `VARCHAR` que são armazenadas externamente devido ao comprimento declarado. Para saber mais sobre as versões do Aurora MySQL que removem essa limitação, consulte Fazer upgrade de clusters de consulta paralela para o Aurora MySQL versão 3.
`Aurora_pq_request_not_chosen_column_virtual`	O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a tabela contém uma coluna virtual.
`Aurora_pq_request_not_chosen_custom_charset`	O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a tabela tem colunas com um conjunto de caracteres personalizado.
`Aurora_pq_request_not_chosen_fast_ddl`	O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a tabela está sendo alterada atualmente por uma instrução `ALTER` DDL rápida.
`Aurora_pq_request_not_chosen_few_pages_outside_buffer_pool`	O número de vezes em que a consulta paralela não foi escolhida, ainda que menos de 95 por cento dos dados da tabela já estivessem no grupo de buffers, porque não havia uma quantidade suficiente de dados da tabela fora do buffer que fizesse a consulta paralela valer a pena.
`Aurora_pq_request_not_chosen_full_text_index`	O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a tabela tem índices de texto completo.
`Aurora_pq_request_not_chosen_high_buffer_pool_pct`	O número de vezes em que a consulta paralela não foi escolhida porque uma alta porcentagem de dados da tabela (no momento, maior do que 95 por cento) já se encontrava no grupo de buffers. Nesses casos, o otimizador determina que a leitura dos dados a partir do grupo de buffers é mais eficiente. Uma declaração `EXPLAIN` pode incrementar esse contador mesmo que a consulta não seja realmente executada.
`Aurora_pq_request_not_chosen_index_hint`	O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a consulta inclui uma dica de índice.
`Aurora_pq_request_not_chosen_innodb_table_format`	O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a tabela usa um formato de linha InnoDB que não é compatível. A consulta paralela do Aurora só se aplica aos formatos de linha `COMPACT`, `REDUNDANT` e `DYNAMIC`.
`Aurora_pq_request_not_chosen_long_trx`	O número de solicitações de consultas paralelas que usaram o caminho de processamento de consultas não paralelas, devido à execução da consulta ter sido iniciada dentro de uma transação de execução demorada. Uma declaração `EXPLAIN` pode incrementar esse contador mesmo que a consulta não seja realmente executada.
`Aurora_pq_request_not_chosen_no_where_clause`	O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a consulta não inclui nenhuma cláusula `WHERE`.
`Aurora_pq_request_not_chosen_range_scan`	O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a consulta usa uma verificação de intervalo em um índice.
`Aurora_pq_request_not_chosen_row_length_too_long`	O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque o comprimento total combinado de todas as colunas é muito longo.
`Aurora_pq_request_not_chosen_small_table`	O número de vezes em que a consulta paralela não foi escolhida devido ao tamanho total da tabela, o que é determinado pelo número de linhas e pelo comprimento médio da linha. Uma declaração `EXPLAIN` pode incrementar esse contador mesmo que a consulta não seja realmente executada.
`Aurora_pq_request_not_chosen_temporary_table`	O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a consulta se refere a tabelas temporárias que usam os tipos de tabela `MyISAM` ou `memory` que não têm suporte.
`Aurora_pq_request_not_chosen_tx_isolation`	O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a consulta usa um nível de isolamento de transação sem suporte. Em instâncias de banco de dados do leitor, a consulta paralela se aplica somente aos níveis de isolamento `REPEATABLE READ` e `READ COMMITTED`.
`Aurora_pq_request_not_chosen_update_delete_stmts`	O número de solicitações de consulta paralela que usam o caminho de processamento de consulta não paralela porque a consulta faz parte de uma instrução `UPDATE` ou `DELETE`.
`Aurora_pq_request_not_chosen_unsupported_access`	O número de solicitações de consultas paralelas que usam o caminho de processamento de consultas não paralelas porque a cláusula `WHERE` não atende aos critérios de consulta paralela. Esse resultado pode ocorrer se a consulta não exigir uma varredura de dados intensiva ou se a consulta for uma instrução `DELETE` ou `UPDATE`.
`Aurora_pq_request_not_chosen_unsupported_storage_type`	O número de solicitações de consulta paralelas que usam o caminho de processamento de consulta não paralelo porque o cluster de banco de dados do Aurora MySQL não está usando uma configuração de armazenamento de cluster compatível do Aurora. Esse parâmetro está disponível no Aurora MySQL versão 3.04 e posterior. Para ter mais informações, consulte Limitações.
`Aurora_pq_request_throttled`	O número de vezes em que a consulta paralela não foi escolhida devido ao número máximo de consultas paralelas simultâneas em execução em uma determinada instância de bancos de dados Aurora.

Como a consulta paralela funciona com construções SQL

Na seção a seguir, você pode encontrar mais detalhes sobre por que determinadas instruções SQL usam ou não usam a consulta paralela. Esta seção também detalha como os recursos do Aurora MySQL interagem com a consulta paralela. Essas informações podem ajudar a diagnosticar problemas de performance de um cluster que usa a consulta paralela ou a entender como a consulta paralela pode ser aplicada em sua workload específica.

A decisão de usar a consulta paralela depende de muitos fatores que ocorrem no momento em que a instrução está em execução. Assim, a consulta paralela pode ser usada para algumas consultas sempre, nunca ou somente sob determinadas condições.

dica

Ao visualizar esses exemplos em HTML, você pode usar o widget Copy (Copiar) no canto superior direito de cada listagem de código para copiar o código SQL e testar por conta própria. O uso do widget Copy (Copiar) evita copiar os caracteres adicionais ao redor das linhas de prompt mysql> e de continuação ->.

Instrução EXPLAIN

Conforme mostrado em exemplos ao longo desta seção, a instrução EXPLAIN indica se cada estágio de uma consulta se qualifica ou não à consulta paralela. Ela também indica quais aspectos de uma consulta são empurrados para a camada de armazenamento. Os itens mais importantes no plano de consulta são os seguintes:

Um valor diferente de NULL na coluna key sugere que a consulta pode ser realizada de maneira eficiente usando buscas com índices, e que a consulta paralela é improvável.
Um valor pequeno na coluna rows (um valor que não esteja na casa dos milhões) sugere que a consulta não acessa uma quantidade de dados suficiente para fazer a consulta paralela valer a pena. Isso significa que consulta paralela é improvável.
A coluna Extra mostra se uma consulta paralela é esperada. Essa saída é semelhante ao exemplo a seguir.
```
Using parallel query (A columns, B filters, C exprs; D extra)
```
O número columns representa quantas colunas são referenciadas no bloco de consultas.

O número filters representa o número de predicados de WHERE que representam uma comparação simples de um valor de coluna com uma constante. A comparação pode ser de igualdade, desigualdade ou intervalo. O Aurora pode paralelizar esses tipos de predicados com mais eficiência.

O número exprs representa o número de expressões, como chamadas de funções, operadores ou outras expressões que também podem ser paralelizadas, embora não com a mesma eficiência que uma condição de filtro.

O número extra representa quantas expressões não podem ser empurradas e são executadas pelo nó de cabeçalho.

Por exemplo, considere a seguinte saída da instrução EXPLAIN.


mysql> explain select p_name, p_mfgr from part
    -> where p_brand is not null
    -> and upper(p_type) is not null
    -> and round(p_retailprice) is not null;
+----+-------------+-------+...+----------+----------------------------------------------------------------------------+
| id | select_type | table |...| rows     | Extra                                                                      |
+----+-------------+-------+...+----------+----------------------------------------------------------------------------+
|  1 | SIMPLE      | part  |...| 20427936 | Using where; Using parallel query (5 columns, 1 filters, 2 exprs; 0 extra) |
+----+-------------+-------+...+----------+----------------------------------------------------------------------------+

A informação da coluna Extra mostra que cinco colunas são extraídas de cada linha para avaliar as condições da consulta e construir o conjunto de resultados. Um predicado de WHERE envolve um filtro, isto é, uma coluna que é diretamente testada na cláusula WHERE. Duas cláusulas WHERE exigem a avaliação das expressões mais complicadas, nesse caso envolvendo chamadas de funções. O campo 0 extra confirma que todas as operações na cláusula WHERE são empurradas para a camada de armazenamento como parte do processamento de consulta paralela.

Nos casos em que a consulta paralela não é escolhida, normalmente é possível deduzir a razão a partir das outras colunas da saída de EXPLAIN. Por exemplo, o valor de rows pode ser muito pequeno ou a coluna possible_keys pode indicar que a consulta pode usar uma busca com índices, em vez de uma varredura com muitos dados. O exemplo a seguir mostra uma consulta em que o otimizador pode estimar que a consulta verificará apenas um pequeno número de linhas. Ele faz isso com base nas características da chave primária. Nesse caso, a consulta paralela não é necessária.


mysql> explain select count(*) from part where p_partkey between 1 and 100;
+----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra                    |
+----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+
|  1 | SIMPLE      | part  | range | PRIMARY       | PRIMARY | 4       | NULL |   99 | Using where; Using index |
+----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+

A saída que mostra se a consulta paralela será usada leva em conta todos os fatores disponíveis no momento em que a instrução EXPLAIN é executada. O otimizador pode fazer uma escolha diferente quando a consulta é de fato executada, caso a situação tenha sido alterada nesse meio-tempo. Por exemplo, EXPLAIN pode relatar que uma instrução usará a consulta paralela. Porém, quando a consulta é executada mais tarde, ela poderá não usar a consulta paralela devido às condições atuais. Essas condições podem incluir várias outras consultas paralelas em execução simultaneamente. Elas também podem incluir linhas sendo excluídas da tabela, um novo índice sendo criado, tempo excessivo em uma transação aberta, e assim por diante.

Cláusula WHERE

Para que uma consulta use a otimização de consulta paralela, ela deve incluir uma cláusula WHERE.

A otimização de consulta paralela acelera vários tipos de expressões usadas na cláusula WHERE:

Comparações simples do valor de uma coluna com uma constante, conhecidas como filtros. Essas comparações são as mais beneficiadas pela transferência para a camada de armazenamento. O número de expressões de filtro em uma consulta é relatado na saída de EXPLAIN.
Outros tipos de expressões na cláusula WHERE também são empurradas para a camada de armazenamento, onde for possível. O número de expressões como essas em uma consulta é relatado na saída de EXPLAIN. Essas expressões podem ser chamadas de funções, operadores LIKE, expressões CASE, e assim por diante.
No momento, determinadas funções e operadores não são empurrados pela consulta paralela. O número dessas expressões em uma consulta é relatado como o contador extra na saída de EXPLAIN. O restante da consulta ainda pode usar a consulta paralela.
Embora as expressões na lista selecionada não sejam empurradas, as consultas que contêm essas funções ainda podem se beneficiar com a redução do tráfego de rede dos resultados intermediários de consultas paralelas. Por exemplo, as consultas que chamam funções de agregação na lista selecionada podem se beneficiar da consulta paralela, ainda que as funções de agregação não sejam empurradas.

Por exemplo, a consulta a seguir faz uma varredura completa na tabela e processa todos os valores da coluna P_BRAND. No entanto, ela não usa a consulta paralela porque não inclui nenhuma cláusula WHERE.


mysql> explain select count(*), p_brand from part group by p_brand;
+----+-------------+-------+------+---------------+------+---------+------+----------+---------------------------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows     | Extra                           |
+----+-------------+-------+------+---------------+------+---------+------+----------+---------------------------------+
|  1 | SIMPLE      | part  | ALL  | NULL          | NULL | NULL    | NULL | 20427936 | Using temporary; Using filesort |
+----+-------------+-------+------+---------------+------+---------+------+----------+---------------------------------+

Por outro lado, a seguinte consulta inclui predicados de WHERE que filtram os resultados e, portanto, a consulta paralela pode ser aplicada:


mysql> explain select count(*), p_brand from part where p_name is not null
    ->   and p_mfgr in ('Manufacturer#1', 'Manufacturer#3') and p_retailprice > 1000
    -> group by p_brand;
+----+...+----------+-------------------------------------------------------------------------------------------------------------+
| id |...| rows     | Extra                                                                                                       |
+----+...+----------+-------------------------------------------------------------------------------------------------------------+
|  1 |...| 20427936 | Using where; Using temporary; Using filesort; Using parallel query (5 columns, 1 filters, 2 exprs; 0 extra) |
+----+...+----------+-------------------------------------------------------------------------------------------------------------+

Se o otimizador estimar que o número de linhas retornadas para um bloco de consultas for pequeno, a consulta paralela não será usada para esse bloco. O exemplo a seguir mostra um caso em que um operador "maior que" na coluna da chave primária é aplicado em milhões de linhas, o que determina o uso da consulta paralela. O teste inverso com "menor que" estima a aplicação em algumas linhas apenas e não usa a consulta paralela.


mysql> explain select count(*) from part where p_partkey > 10;
+----+...+----------+----------------------------------------------------------------------------+
| id |...| rows     | Extra                                                                      |
+----+...+----------+----------------------------------------------------------------------------+
|  1 |...| 20427936 | Using where; Using parallel query (1 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+----------+----------------------------------------------------------------------------+

mysql> explain select count(*) from part where p_partkey < 10;
+----+...+------+--------------------------+
| id |...| rows | Extra                    |
+----+...+------+--------------------------+
|  1 |...|    9 | Using where; Using index |
+----+...+------+--------------------------+

Linguagem de definição de dados (DDL)

No Aurora MySQL versão 2, a consulta paralela só está disponível para tabelas cujas operações de linguagem de definição de dados (DDL) rápida estão pendentes. No Aurora MySQL versão 3, é possível utilizar a consulta paralela em uma tabela ao mesmo tempo que uma operação de DDL instantânea.

A DDL instantânea no Aurora MySQL versão 3 substitui o recurso de DDL rápida no Aurora MySQL versão 2. Para saber mais sobre a DDL instantânea, consulte DDL instantânea (Aurora MySQL versão 3).

Tipos de dados de coluna

No Aurora MySQL versão 3, a consulta paralela pode funcionar com tabelas que contêm colunas com os tipos de dados TEXT,BLOB,JSON eGEOMETRY. Ela também pode funcionar com colunas VARCHAR e CHAR com um comprimento máximo declarado superior a 768 bytes. Se a consulta fizer referência a colunas que contenham tipos de objetos grandes, o trabalho adicional para recuperá-las adicionará uma certa sobrecarga ao processamento das consultas. Nesse caso, verifique se a consulta é capaz de omitir as referências a essas colunas. Caso contrário, execute benchmarks para confirmar se essas consultas são mais rápidas com a consulta paralela habilitada ou desabilitada.

No Aurora MySQL versão 2, a consulta paralela apresenta estas limitações para tipos de objetos grandes:

Os tipos de dados TEXT, BLOB, JSON e GEOMETRY não são compatíveis com a consulta paralela. Uma consulta que faça referência a qualquer coluna desses tipos não pode usar a consulta paralela.
Colunas de tamanho variável (tipos de dados VARCHAR e CHAR) são compatíveis com a consulta paralela até o tamanho máximo declarado de 768 bytes. Uma consulta que faça referência a qualquer coluna de um tipo declarado com um tamanho máximo maior não poderá usar a consulta paralela. Para colunas que usam conjuntos de caracteres multibyte, o limite de bytes leva em conta o número máximo de bytes no conjunto de caracteres. Por exemplo, para o conjunto de caracteres utf8mb4 (que tem um tamanho máximo de caracteres de 4 bytes), uma coluna VARCHAR(192) é compatível com a consulta paralela, mas uma coluna VARCHAR(193) não é.

Tabelas particionadas

É possível utilizar tabelas particionadas com consulta paralela no Aurora MySQL versão 3. Como essas tabelas particionadas são representadas internamente como várias tabelas menores, uma consulta que utiliza a consulta paralela em uma tabela não particionada pode não utilizar a consulta paralela em uma tabela particionada idêntica. O Aurora MySQL considera se cada partição é grande o suficiente a ponto de se qualificar para a otimização de consulta paralela, em vez de avaliar o tamanho da tabela inteira. Verifique se a variável de status Aurora_pq_request_not_chosen_small_table é incrementada quando uma consulta em uma tabela particionada não utiliza a consulta paralela na ocasião esperada.

Por exemplo, considere uma tabela particionada com PARTITION BY HASH (column) PARTITIONS 2 e outra tabela particionada com PARTITION BY HASH (column) PARTITIONS 10. Na tabela com duas partições, estas são cinco vezes maiores que a tabela com dez partições. Portanto, é mais provável que a consulta paralela seja utilizada para consultas na tabela contendo menos partições. No exemplo a seguir, a tabela PART_BIG_PARTITIONS apresenta duas partições e PART_SMALL_PARTITIONS apresenta dez partições. Com dados idênticos, são maiores as chances de que a consulta paralela seja utilizada para a tabela com menos partições grandes.



mysql> explain select count(*), p_brand from part_big_partitions where p_name is not null
    ->   and p_mfgr in ('Manufacturer#1', 'Manufacturer#3') and p_retailprice > 1000 group by p_brand;
+----+-------------+---------------------+------------+-------------------------------------------------------------------------------------------------------------------+
| id | select_type | table               | partitions | Extra                                                                                                             |
+----+-------------+---------------------+------------+-------------------------------------------------------------------------------------------------------------------+
|  1 | SIMPLE      | part_big_partitions | p0,p1      | Using where; Using temporary; Using parallel query (4 columns, 1 filters, 1 exprs; 0 extra; 1 group-bys, 1 aggrs) |
+----+-------------+---------------------+------------+-------------------------------------------------------------------------------------------------------------------+

mysql> explain select count(*), p_brand from part_small_partitions where p_name is not null
    ->   and p_mfgr in ('Manufacturer#1', 'Manufacturer#3') and p_retailprice > 1000 group by p_brand;
+----+-------------+-----------------------+-------------------------------+------------------------------+
| id | select_type | table                 | partitions                    | Extra                        |
+----+-------------+-----------------------+-------------------------------+------------------------------+
|  1 | SIMPLE      | part_small_partitions | p0,p1,p2,p3,p4,p5,p6,p7,p8,p9 | Using where; Using temporary |
+----+-------------+-----------------------+-------------------------------+------------------------------+

Funções agregadas, cláusulas GROUP BY e cláusulas HAVING.

As consultas que envolvem as funções agregadas frequentemente são boas candidatas ao uso da consulta paralela, pois envolvem a varredura de grandes números de linhas em tabelas grandes.

No Aurora MySQL 3, a consulta paralela pode otimizar chamadas de função agregadas na lista de seleção e na cláusula HAVING.

Antes do Aurora MySQL 3, chamadas de funções agregadas na lista selecionada ou na cláusula HAVING não são enviadas para a camada de armazenamento. No entanto, a consulta paralela ainda pode melhorar a performance dessas consultas com funções agregadas. Para isso, ela primeiro extrai os valores das colunas das páginas de dados brutos em paralelo na camada de armazenamento. Em seguida, ela transmite esses valores de volta para o nó de cabeçalho em um formato de tupla compacta, em vez de páginas inteiras de dados. Como sempre, a consulta precisa ter pelo menos um predicado WHERE para que a consulta paralela seja ativada.

Os exemplos simples a seguir ilustram os tipos de consultas agregadas que podem se beneficiar da consulta paralela. Eles fazem isso retornando resultados intermediários de forma compacta para o nó de cabeçalho ou filtrando as linhas que não encontram correspondência dos resultados intermediários, ou ambos.


mysql> explain select sql_no_cache count(distinct p_brand) from part where p_mfgr = 'Manufacturer#5';
+----+...+----------------------------------------------------------------------------+
| id |...| Extra                                                                      |
+----+...+----------------------------------------------------------------------------+
|  1 |...| Using where; Using parallel query (2 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+----------------------------------------------------------------------------+

mysql> explain select sql_no_cache p_mfgr from part where p_retailprice > 1000 group by p_mfgr having count(*) > 100;
+----+...+-------------------------------------------------------------------------------------------------------------+
| id |...| Extra                                                                                                       |
+----+...+-------------------------------------------------------------------------------------------------------------+
|  1 |...| Using where; Using temporary; Using filesort; Using parallel query (3 columns, 0 filters, 1 exprs; 0 extra) |
+----+...+-------------------------------------------------------------------------------------------------------------+

Chamadas de funções na cláusula WHERE

O Aurora pode aplicar a otimização de consulta paralela em chamadas para a maioria das funções incorporadas na cláusula WHERE. A paralelização dessas chamadas de funções alivia alguma workload da CPU a partir do nó de cabeçalho. A avaliação das funções de predicado em paralelo durante o estágio inicial da consulta ajuda o Aurora a minimizar a quantidade de dados transmitidos e processados nos estágios posteriores.

No momento, a paralelização não se aplica às chamadas de funções na lista selecionada. Essas funções são avaliadas pelo nó de cabeçalho, mesmo que as chamadas de funções idênticas apareçam na cláusula WHERE. Os valores originais das colunas relevantes são incluídos nas tuplas transmitidas dos nós de armazenamento de volta até o nó de cabeçalho. O nó de cabeçalho realiza qualquer transformação, como UPPER, CONCATENATE e assim por diante, para produzir os valores finais do conjunto de resultados.

No exemplo a seguir, a consulta paralela paraleliza a chamada LOWER porque ela aparece na cláusula WHERE. A consulta paralela não afeta as chamadas SUBSTR e UPPER porque elas aparecem na lista selecionada.


mysql> explain select sql_no_cache distinct substr(upper(p_name),1,5) from part
    -> where lower(p_name) like '%cornflower%' or lower(p_name) like '%goldenrod%';
+----+...+---------------------------------------------------------------------------------------------+
| id |...| Extra                                                                                       |
+----+...+---------------------------------------------------------------------------------------------+
|  1 |...| Using where; Using temporary; Using parallel query (2 columns, 0 filters, 1 exprs; 0 extra) |
+----+...+---------------------------------------------------------------------------------------------+

As mesmas considerações se aplicam a outras expressões, como as expressões CASE ou os operadores LIKE. O exemplo a seguir mostra que a consulta paralela avalia a expressão CASE e os operadores LIKE na cláusula WHERE.


mysql> explain select p_mfgr, p_retailprice from part
    -> where p_retailprice > case p_mfgr
    ->   when 'Manufacturer#1' then 1000
    ->   when 'Manufacturer#2' then 1200
    ->   else 950
    -> end
    -> and p_name like '%vanilla%'
    -> group by p_retailprice;
+----+...+-------------------------------------------------------------------------------------------------------------+
| id |...| Extra                                                                                                       |
+----+...+-------------------------------------------------------------------------------------------------------------+
|  1 |...| Using where; Using temporary; Using filesort; Using parallel query (4 columns, 0 filters, 2 exprs; 0 extra) |
+----+...+-------------------------------------------------------------------------------------------------------------+

Cláusula LIMIT

No momento, a consulta paralela não é usada para blocos de consulta que incluam uma cláusula LIMIT. A consulta paralela ainda pode ser usada em fases anteriores da consulta com GROUP by, ORDER BY ou junções.

Operadores de comparação

O otimizador estima quantas linhas serão examinadas para avaliar os operadores de comparação e determina se vai usar a consulta paralela com base nessa estimativa.

O primeiro exemplo, a seguir, mostra que uma comparação de igualdade com uma coluna de chave primária pode ser realizada de maneira eficiente sem a consulta paralela. O segundo exemplo, a seguir, mostra que uma comparação semelhante com uma coluna não indexada exige a varredura de milhões de linhas e, portanto, pode se beneficiar da consulta paralela.


mysql> explain select * from part where p_partkey = 10;
+----+...+------+-------+
| id |...| rows | Extra |
+----+...+------+-------+
|  1 |...|    1 | NULL  |
+----+...+------+-------+

mysql> explain select * from part where p_type = 'LARGE BRUSHED BRASS';
+----+...+----------+----------------------------------------------------------------------------+
| id |...| rows     | Extra                                                                      |
+----+...+----------+----------------------------------------------------------------------------+
|  1 |...| 20427936 | Using where; Using parallel query (9 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+----------+----------------------------------------------------------------------------+

As mesmas considerações se aplicam aos testes de desigualdade e a comparações com intervalos, como menor que, maior que, igual a ou BETWEEN. O otimizador estima o número de linhas que serão examinadas e determina se vale a pena usar a consulta paralela com base no volume total de E/S.

Junções

As consultas que usam junções com grandes tabelas normalmente envolvem operações com muitos dados que se beneficiam da otimização de consulta paralela. As comparações de valores de colunas entre várias tabelas (ou seja, os próprios predicados das junções) não são paralelizadas no momento. No entanto, a consulta paralela pode empurrar uma parte do processamento interno de outras fases da junção, como a construção do filtro Bloom durante uma junção hash. A consulta paralela pode ser aplicada a consultas de junções, mesmo sem uma cláusula WHERE. Portanto, uma consulta de junção é uma exceção à regra de que uma cláusula WHERE é necessária para o uso da consulta paralela.

Cada fase do processamento da junção é avaliado para verificar se ela se qualifica para a consulta paralela. Se mais de uma fase puder usar a consulta paralela, essas fases serão executadas em sequência. Assim, cada consulta de junção conta como uma única sessão de consulta paralela em termos de limites de simultaneidade.

Por exemplo, quando uma consulta de junção incluir predicados WHERE para filtrar as linhas de uma das tabelas associadas, essa opção de filtragem poderá usar a consulta paralela. Em um outro exemplo, vamos supor que uma consulta de junção use o mecanismo de junção hash para unir uma tabela grande a uma tabela pequena. Nesse caso, a varredura da tabela para produzir a estrutura de dados do filtro Bloom pode conseguir usar a consulta paralela.

nota

A consulta paralela é normalmente usada para tipos de consultas que consomem muitos recursos e que se beneficiam da otimização de junções de hash. O método de ativação da otimização de junções de hash depende da versão do Aurora MySQL. Para obter detalhes sobre cada versão, consulte Habilitar a junção de hash para clusters de consulta paralela. 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.


mysql> explain select count(*) from orders join customer where o_custkey = c_custkey;
+----+...+----------+-------+---------------+-------------+...+-----------+-----------------------------------------------------------------------------------------------------------------+
| id |...| table    | type  | possible_keys | key         |...| rows      | Extra                                                                                                           |
+----+...+----------+-------+---------------+-------------+...+-----------+-----------------------------------------------------------------------------------------------------------------+
|  1 |...| customer | index | PRIMARY       | c_nationkey |...|  15051972 | Using index                                                                                                     |
|  1 |...| orders   | ALL   | o_custkey     | NULL        |...| 154545408 | Using join buffer (Hash Join Outer table orders); Using parallel query (1 columns, 0 filters, 1 exprs; 0 extra) |
+----+...+----------+-------+---------------+-------------+...+-----------+-----------------------------------------------------------------------------------------------------------------+

Para uma consulta de junção que usa o mecanismo de loop aninhado, o bloco de loop aninhado mais externo poderá usar a consulta paralela. O uso da consulta paralela depende dos mesmos fatores de sempre, como a presença de condições de filtragem adicionais na cláusula WHERE.


mysql> -- Nested loop join with extra filter conditions can use parallel query.
mysql> explain select count(*) from part, partsupp where p_partkey != ps_partkey and p_name is not null and ps_availqty > 0;
+----+-------------+----------+...+----------+----------------------------------------------------------------------------+
| id | select_type | table    |...| rows     | Extra                                                                      |
+----+-------------+----------+...+----------+----------------------------------------------------------------------------+
|  1 | SIMPLE      | part     |...| 20427936 | Using where; Using parallel query (2 columns, 1 filters, 0 exprs; 0 extra) |
|  1 | SIMPLE      | partsupp |...| 78164450 | Using where; Using join buffer (Block Nested Loop)                         |
+----+-------------+----------+...+----------+----------------------------------------------------------------------------+

Subconsultas

O bloco de consulta externa e o bloco de subconsulta interna podem usar a consulta paralela ou não. Isso é determinado com base nas características habituais da tabela, na cláusula WHERE e assim por diante, para cada bloco. Por exemplo, a consulta a seguir usa a consulta paralela para o bloco de subconsultas mas não para o bloco mais externo.


mysql> explain select count(*) from part where
   --> p_partkey < (select max(p_partkey) from part where p_name like '%vanilla%');
+----+-------------+...+----------+----------------------------------------------------------------------------+
| id | select_type |...| rows     | Extra                                                                      |
+----+-------------+...+----------+----------------------------------------------------------------------------+
|  1 | PRIMARY     |...|     NULL | Impossible WHERE noticed after reading const tables                        |
|  2 | SUBQUERY    |...| 20427936 | Using where; Using parallel query (2 columns, 0 filters, 1 exprs; 0 extra) |
+----+-------------+...+----------+----------------------------------------------------------------------------+

No momento, as subconsultas correlacionadas não podem usar a otimização de consulta paralela.

UNION

Cada bloco de consultas em uma consulta UNION pode usar a consulta paralela ou não, dependendo das características da tabela, da cláusula WHERE etc., para cada parte da UNION.


mysql> explain select p_partkey from part where p_name like '%choco_ate%'
    -> union select p_partkey from part where p_name like '%vanil_a%';
+----+----------------+...+----------+----------------------------------------------------------------------------+
| id | select_type    |...| rows     | Extra                                                                      |
+----+----------------+...+----------+----------------------------------------------------------------------------+
|  1 | PRIMARY        |...| 20427936 | Using where; Using parallel query (2 columns, 0 filters, 1 exprs; 0 extra) |
|  2 | UNION          |...| 20427936 | Using where; Using parallel query (2 columns, 0 filters, 1 exprs; 0 extra) |
| NULL | UNION RESULT | <union1,2> |...|     NULL | Using temporary                                           |
+----+--------------+...+----------+----------------------------------------------------------------------------+

nota

Cada cláusula UNION dentro da consulta é executada sequencialmente. Mesmo que a consulta inclua vários estágios que utilizem a consulta paralela, ela executa apenas uma única consulta paralela de cada vez. Portanto, mesmo uma consulta complexa com vários estágios conta apenas como sendo uma em relação ao limite de consultas paralelas simultâneas.

Visualizações

O otimizador reescreve as consultas que usam visualizações como consultas mais longas que usam tabelas subjacentes. Assim, a consulta paralela funciona da mesma forma, sejam as referências de tabelas visualizações ou tabelas reais. Todas as mesmas considerações que se aplicam ao uso de consultas paralelas para uma consulta, e a quais partes são empurradas, são aplicáveis à consulta final que é reescrita.

Por exemplo, o plano de consulta a seguir mostra uma definição de visualização que normalmente não usa a consulta paralela. Quando a visualização é consultada com cláusulas WHERE adicionais, o Aurora MySQL usa a consulta paralela.


mysql> create view part_view as select * from part;
mysql> explain select count(*) from part_view where p_partkey is not null;
+----+...+----------+----------------------------------------------------------------------------+
| id |...| rows     | Extra                                                                      |
+----+...+----------+----------------------------------------------------------------------------+
|  1 |...| 20427936 | Using where; Using parallel query (1 columns, 0 filters, 0 exprs; 1 extra) |
+----+...+----------+----------------------------------------------------------------------------+

Instruções na linguagem de manipulação de dados (DML)

A instrução INSERT pode usar a consulta paralela na fase de processamento SELECT, caso a parte SELECT atenda às outras condições para usar a consulta paralela.


mysql> create table part_subset like part;
mysql> explain insert into part_subset select * from part where p_mfgr = 'Manufacturer#1';
+----+...+----------+----------------------------------------------------------------------------+
| id |...| rows     | Extra                                                                      |
+----+...+----------+----------------------------------------------------------------------------+
|  1 |...| 20427936 | Using where; Using parallel query (9 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+----------+----------------------------------------------------------------------------+

nota

Normalmente, após uma instrução INSERT, os dados das linhas recentemente inseridas ficam no grupo de buffers. Portanto, uma tabela pode não se qualificar para a consulta paralela imediatamente após a inserção de um grande número de linhas. Mais tarde, depois que os dados forem removidos do grupo de buffers durante uma operação normal, as consultas que acessam essa tabela poderão começar a usar a consulta paralela novamente.

A instrução CREATE TABLE AS SELECT não usa a consulta paralela, mesmo que a porção SELECT da instrução seja qualificada para usar a consulta paralela. O aspecto de DDL dessa instrução torna ela incompatível com o processamento de consultas paralelas. Por outro lado, na instrução INSERT ... SELECT, a porção SELECT pode usar a consulta paralela.

A consulta paralela nunca é usada em instruções DELETE ou UPDATE, independentemente do tamanho da tabela e dos predicados na cláusula WHERE.


mysql> explain delete from part where p_name is not null;
+----+-------------+...+----------+-------------+
| id | select_type |...| rows     | Extra       |
+----+-------------+...+----------+-------------+
|  1 | SIMPLE      |...| 20427936 | Using where |
+----+-------------+...+----------+-------------+

Transações e bloqueio

É possível usar todos os níveis de isolamento na instância primária do Aurora.

Em instâncias de banco de dados do leitor do Aurora, a consulta paralela se aplica a instruções executadas sob o nível de isolamento REPEATABLE READ. O Aurora MySQL versão 2.09 e versões posteriores também podem usar o nível de isolamento READ COMMITTED em instâncias de banco de dados do leitor. O nível de isolamento padrão para instâncias de banco de dados do leitor do Aurora é REPEATABLE READ. Para usar o nível de isolamento READ COMMITTED em instâncias de banco de dados de leitor, é necessário definir a opção de configuração aurora_read_replica_read_committed no nível da sessão. O nível de isolamento READ COMMITTED para instâncias de leitor está em conformidade com o comportamento padrão SQL. No entanto, o isolamento é menos rigoroso em instâncias de leitor do que quando as consultas usam o nível de isolamento READ COMMITTED na instância de gravador.

Para saber mais sobre níveis de isolamento do Aurora, especialmente as diferenças em READ COMMITTED entre instâncias de gravador e de leitor, consulte Níveis de isolamento do Aurora MySQL.

Após a conclusão de uma grande transação, as estatísticas da tabela podem ficar obsoletas. Tais estatísticas obsoletas podem exigir o uso de uma instrução ANALYZE TABLE para que o Aurora possa estimar o número de linhas com precisão. Uma instrução em DML de grande escala também pode trazer uma porção substancial dos dados da tabela para o grupo de buffers. A presença desses dados no grupo de buffers pode levar à redução da frequência de uso da consulta paralela para essa tabela até que os dados sejam removidos do grupo.

Quando sua sessão está em uma transação demorada (por padrão, 10 minutos), as consultas adicionais dentro dessa sessão não usam a consulta paralela. Também é possível que o tempo limite seja esgotado durante uma consulta única de longa duração. Esse tipo de tempo limite esgotado pode ocorrer se a execução da consulta se estender por um tempo maior do que o intervalo máximo (atualmente, 10 minutos) antes de o processamento da consulta paralela começar.

Você pode reduzir a probabilidade de iniciar uma transação de longa duração acidentalmente definindo autocommit=1 nas sessões mysql, onde você executa as consultas ad hoc (de execução única). Até mesmo uma instrução SELECT em uma tabela inicia uma transação criando uma visualização de leitura. Uma visualização de leitura é um conjunto de dados consistente para as consultas posteriores que permanecem até que a transação seja confirmada. Esteja ciente dessa restrição também ao usar aplicativos JDBC ou ODBC com o Aurora, pois eles podem estar sendo executados com a configuração de autocommit desativada.

O exemplo a seguir mostra como a execução de uma consulta em uma tabela com a configuração de autocommit desativada cria uma visualização de leitura que inicia implicitamente uma transação. As consultas executadas logo em seguida ainda podem usar a consulta paralela. No entanto, após uma pausa de vários minutos, as consultas não se qualificam mais para a consulta paralela. O encerramento da transação com COMMIT ou ROLLBACK restaura a possibilidade de qualificação para a consulta paralela.


mysql> set autocommit=0;

mysql> explain select sql_no_cache count(*) from part where p_retailprice > 10.0;
+----+...+---------+----------------------------------------------------------------------------+
| id |...| rows    | Extra                                                                      |
+----+...+---------+----------------------------------------------------------------------------+
|  1 |...| 2976129 | Using where; Using parallel query (1 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+---------+----------------------------------------------------------------------------+

mysql> select sleep(720); explain select sql_no_cache count(*) from part where p_retailprice > 10.0;
+------------+
| sleep(720) |
+------------+
|          0 |
+------------+
1 row in set (12 min 0.00 sec)

+----+...+---------+-------------+
| id |...| rows    | Extra       |
+----+...+---------+-------------+
|  1 |...| 2976129 | Using where |
+----+...+---------+-------------+

mysql> commit;

mysql> explain select sql_no_cache count(*) from part where p_retailprice > 10.0;
+----+...+---------+----------------------------------------------------------------------------+
| id |...| rows    | Extra                                                                      |
+----+...+---------+----------------------------------------------------------------------------+
|  1 |...| 2976129 | Using where; Using parallel query (1 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+---------+----------------------------------------------------------------------------+

Para ver quantas vezes as consultas não foram qualificadas para a consulta paralela porque estavam dentro de transações de longa duração, verifique a variável de status Aurora_pq_request_not_chosen_long_trx.


mysql> show global status like '%pq%trx%';
+---------------------------------------+-------+
| Variable_name                         | Value |
+---------------------------------------+-------+
| Aurora_pq_request_not_chosen_long_trx | 4     |
+-------------------------------+-------+

As instruções SELECT que obtêm bloqueios, como as sintaxes SELECT FOR UPDATE ou SELECT LOCK IN SHARE MODE, não podem usar a consulta paralela.

A consulta paralela pode funcionar para uma tabela que seja bloqueada por uma instrução LOCK TABLES.


mysql> explain select o_orderpriority, o_shippriority from orders where o_clerk = 'Clerk#000095055';
+----+...+-----------+----------------------------------------------------------------------------+
| id |...| rows      | Extra                                                                      |
+----+...+-----------+----------------------------------------------------------------------------+
|  1 |...| 154545408 | Using where; Using parallel query (3 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+-----------+----------------------------------------------------------------------------+

mysql> explain select o_orderpriority, o_shippriority from orders where o_clerk = 'Clerk#000095055' for update;
+----+...+-----------+-------------+
| id |...| rows      | Extra       |
+----+...+-----------+-------------+
|  1 |...| 154545408 | Using where |
+----+...+-----------+-------------+

Índices de árvore B

As estatísticas coletadas pela instrução ANALYZE TABLE ajudam o otimizador a decidir quando usar a consulta paralela ou as buscas com índice, com base nas características dos dados de cada coluna. Mantenha as estatísticas atualizadas com a execução de ANALYZE TABLE após as operações DML que fazem alterações substanciais nos dados dentro de uma tabela.

Se as buscas com índices podem executar uma consulta de maneira eficiente sem uma varredura com muitos dados, o Aurora pode usar buscas com índices. Isso evita a sobrecarga do processamento de consultas paralelas. Também existem limites de simultaneidade para o número de consultas paralelas que podem ser executadas simultaneamente em um cluster de bancos de dados Aurora. Certifique-se de usar as práticas recomendadas na indexação de suas tabelas, de modo que suas consultas mais frequentes e aquelas que são mais usadas de forma simultânea utilizem buscas com índices.

Índices de pesquisa de texto completo (FTS)

No momento, a consulta paralela não é usada em tabelas que contêm um índice de pesquisa de texto completo, independentemente de a consulta fazer referência ou não a colunas indexadas dessa forma ou usar o operador MATCH.

Virtual columns

No momento, a consulta paralela não é usada para tabelas que contêm uma coluna virtual, independentemente de a consulta se referir a qualquer coluna virtual.

Mecanismos de armazenamento em cache integrados

O Aurora inclui mecanismos de armazenamento em cache incorporados: o grupo de buffers e o cache de consultas. O otimizador do Aurora escolhe um entre esses mecanismos de armazenamento em cache e a consulta paralela de acordo com a eficiência oferecida por cada um deles para cada consulta específica.

Quando uma consulta paralela filtra as linhas, e transforma e extrai valores das colunas, os dados são transmitidos de volta para o nó de cabeçalho como tuplas em vez de páginas de dados. Portanto, a execução de uma consulta paralela não adiciona páginas ao grupo de buffers ou remove páginas que já estão no grupo de buffers.

O Aurora verifica o número de páginas de dados da tabela que estão presentes no grupo de buffers e a proporção dos dados da tabela que esse número representa. O Aurora usa essas informações para determinar se é mais eficiente usar a consulta paralela (e ignorar os dados presentes no grupo de buffers). Como alternativa, o Aurora pode usar o caminho de processamento de consulta não paralela, que usa os dados armazenados em cache no grupo de buffers. Quais páginas são armazenadas em cache e como as consultas com muitos dados afetam o armazenamento em cache e a remoção vai depender das configurações relacionadas ao grupo de buffers. Portanto, pode ser difícil prever se uma consulta específica vai usar a consulta paralela, pois a escolha depende de dados que estão em constante mudança dentro do grupo de buffers.

Além disso, o Aurora impõe limites de simultaneidade para as consultas paralelas. Como nem toda consulta usa a consulta paralela, em geral as tabelas que são acessadas por várias consultas simultaneamente têm uma porção substancial de seus dados no grupo de buffers. Portanto, o Aurora muitas vezes não escolhe essas tabelas para a consulta paralela.

Quando você executa uma sequência de consultas não paralelas na mesma tabela, a primeira consulta pode ficar lenta devido à ausência de dados do grupo de buffers. Em seguida, a segunda consulta, bem como as subsequentes, são muito mais rápidas porque o grupo de buffers agora está "aquecido". As consultas paralelas normalmente apresentam uma performance consistente desde a primeira consulta em uma tabela. Ao conduzir testes de performance, compare as consultas não paralelas tanto com um grupo de buffers ocioso quanto com um aquecido. Em alguns casos, os resultados com um grupo de buffers aquecido pode ser comparável aos tempos obtidos com a consulta paralela. Nesses casos, considere fatores como a frequência de consultas em relação a essa tabela. Considere também se vale a pena manter os dados dessa tabela no grupo de buffer.

O cache de consultas evita a que a consulta seja executada novamente quando uma consulta idêntica é enviada e a tabela subjacente não foi alterada. As consultas otimizadas pelo recurso de consulta paralela podem acessar o cache de consulta, tornando-as efetivamente instantâneas quando executadas novamente.

nota

Ao conduzir comparações de performance, o cache de consulta pode apresentar tempos artificialmente baixos. Portanto, em situações de comparação você pode usar o aviso sql_no_cache. Esse aviso evita que o resultado seja obtido do cache da consulta, ainda que essa mesma consulta tenha sido executada anteriormente. O aviso vem imediatamente após a instrução SELECT em uma consulta. Muitos exemplos de consultas paralelas neste tópico incluem essa dica, a fim de tornar os tempos de consulta comparáveis entre as versões da consulta para as quais a consulta paralela está habilitada ou desabilitada.

Lembre-se de remover esse aviso de seu código-fonte ao implantar o uso de consulta paralela na produção.

Dicas do Optimizer

Outra forma de controlar o Optimizer é usar dicas do Optimizer, que podem ser especificadas em instruções individuais. Por exemplo, é possível ativar a otimização para uma tabela em uma instrução e, depois, desativá-la para outra tabela. Para ter mais informações sobre essas dicas, consulte Dicas do Optimizer no Guia de referência do MySQL.

É possível usar dicas SQL com consultas do Aurora MySQL para ajustar a performance. Também é possível usar dicas para impedir que planos de execução para consultas importantes sejam alterados devido a condições imprevisíveis.

Estendemos o recurso de dicas de SQL para ajudar você a controlar as opções do Optimizer para seus planos de consulta. Essas dicas se aplicam a consultas que usam a otimização de consultas paralelas. Para ter mais informações, consulte Dicas do Aurora MySQL.

Tabelas temporárias MyISAM

A otimização de consulta paralela se aplica somente a tabelas InnoDB. Como o Aurora MySQL usa o MyISAM nos bastidores para tabelas temporárias, as fases de consulta internas que envolvem tabelas temporárias nunca usam a consulta paralela. Essas fases da consulta são indicadas por Using temporary na saída de EXPLAIN.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

O banco de dados está criando tabelas temporárias no disco

Auditoria avançada no Aurora MySQL