SET em ambientes padrão, mesmo utilizando versões recentes como o MySQL 8.0.43. (Apenas em versões como HeatWave e MySQL 9).Ambiente e premissas.
Para manter total coerência ao post anterior, os testes descritos na sequência foram realizados no seguinte cenário:
- MySQL 8.0.43
- Buil padrão (não debug).
- Ambiente homologação (HML).
- Hypergraph desativo por default.
Sendo um cenário mais parecido com a maioria dos ambientes MySQL atuais.
Onde o Hypergraph deveria fazer diferença.
Se consideramos apenas a teoria, o Hypergraph foi pensado exatamente para situações como:
- Queries com múltiplos JOINs.
- Diferentes ordenações.
- Impacto na decisão inicial para o custo final.
- Casos onde o otimizador clássico precisaria “podar” o espaço de busca.
Em resumo:
JOINs complexos são o “habitat” natural do Hypergraph Optimizer.
E será exatamente este tipo de consulta que iremos demonstrar neste post.
Construindo queries mais agressivas.
Lembrando que neste post, seguiremos utilizando nossa base Sysbench, com o uso na tabela SBTEST1 cotendo aproximadamente 1 milhão de registros.
Para aproximarmos de um cenário mais realista, e comúm em alguns sistemas, utilizei o “auto-joins” algo frequente visto em:
- Relatórios complexo.
- Queries mais analíticas.
Exemplo:
|
1 2 3 4 |
EXPLAIN ANALYZE SELECT COUNT(*) FROM sbtest1 t1 JOIN sbtest1 t2 ON t1.k = t2.k JOIN sbtest1 t3 ON t2.k = t3.k WHERE t1.k BETWEEN 100000 AND 300000 AND t2.id < 500000; |
Essa query já apresenta várias características importantes com:
- Múltiplos caminhos válidos de execução
- Forte dependência de cardinalidade
- Impacto direto da ordem dos JOINs
Sendo assim, esta é uma querie exata onde o otimizador hypergraph deveria entregar planos melhores.
Reescrevendo a query: a ordem ainda importa!!
Um compartamento muito comum entre DBA’s é a tentativa de “ajudar” o otimizador clássico reescrevendo a consulta. (Obs: a alguns post atrás, trouxe alguns exemplos).
Por exemplo, alterando a ordem do JOINs:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
NOVO: EXPLAIN ANALYZE SELECT COUNT(*) FROM sbtest1 t3 JOIN sbtest1 t2 ON t2.k = t3.k JOIN sbtest1 t1 ON t1.k = t2.k WHERE t1.k BETWEEN 100000 AND 300000 AND t2.id < 500000; ANTERIOR: EXPLAIN ANALYZE SELECT COUNT(*) FROM sbtest1 t1 JOIN sbtest1 t2 ON t1.k = t2.k JOIN sbtest1 t3 ON t2.k = t3.k WHERE t1.k BETWEEN 100000 AND 300000 AND t2.id < 500000; |
Se o hypergraph estivesse ativo, a ordem escrita no SQL deveria importar muito menos, ja que o plano seria avaliado de forma global.
Na prática, no MySQL 8.0.43 em build padrões, o que notei foi:
- Mudanças claras no plano de execução.
- Diferenças no custo estimado.
- Decisões fortemente influenciadas pela ordem e pelos filtros.
Deixando um reforço crucial:
“Em ambientes reais, o otimizador clássico ainda toma decisões majoritariamente locais, não globais.”
O papel da cardinalidade e das estatísticas.
Durante os testes demonstrados, executei também o ANALYZE TABLE e os efeitos que tive:
- Algumas estimativas melhoraram.
- Alguns planos tiveram mais estabilidade.
- E algumas mudanças no custo estimado.
Mas o importante é:
Estatísticas corretas ajudam, mas não mudam o modelo de decisão do otimizador.
Mesmo com estatísticas atualizadas, o MySQL continua limitado a:
- Reduzir o espaço de busca
- Evitar avaliar combinações mais complexas
E isto que vimos, não é um BUG…. é apenas uma consequência direta do modelo clássico de otimização.
Indo além, utilizando o MySQL 9.7.
A partir das versões mais recentes do MySQL 9, a Oracle começou a introduzir versões Early Access, voltadas exclusivamente para testes e feedback da comunidade. Nesses builds, o Hypergraph Optimizer passa a estar disponível de forma experimental, permitindo observar seu comportamento fora de um build DEBUG.
Ativando o Hypergraph via SET -> MySQL 9.7.
Aqui entra o comando-chave (que não funcionava antes)…. rsrsrs:
|
1 |
SET SESSION optimizer_switch='hypergraph_optimizer=ON'; |
Agora, utilizando as mesmas queries anteriores, como a feature desativa e ativada.
Off:
On:
O que começa mudar utilizando a nova versão 9.7.
Aqui é muito importante manter sobriedade técnica:
Mesmo utilizando exatamente os mesmos dados e consultas, algumas diferenças começam a surgir no MySQL 9.7 com o Hypergraph ativado:
- A ordem escrita dos JOINs passa a ter menos impacto direto no plano final
- O planejamento se torna mais estável entre reescritas da mesma query
- O otimizador passa a avaliar a consulta de forma mais global, e não apenas por decisões locais encadeadas
Mas, galera lembre-se:
O MySQL 9.7 utilizado aqui é um build Early Access, destinado apenas a testes e feedback. O Hypergraph Optimizer ainda não elimina a necessidade de índices corretos, estatísticas atualizadas ou boa modelagem de dados, ele apenas muda a forma como os planos são avaliados.
Conclusão.
No blog 1, mostrei a todos o porque não conseguimos ativar o Hypergraph Optimizer no MySQL 8.0.43. Porém, para features mais recentes existe a possibilidade do USO da váriavel (Heatwave e MySQL 9.7).
Neste blog, dei continuidade trazendo a todos, onde de fato o otimizador faria a diferença, e como na prática ainda estamos presos as decisões do otimizador clássico em ambiente REAIS, mas futuramente com a vinda do MySQL 9.7 o cenário mudará.
No próximo blog e o último desta série, vamos sair dos ambientes padrões e entra no MySQL Debug. E mostrarei o Hypergraph em ação.
Como os planos são avaliados e porque ele apresenta uma evolução no futuro do MySQL.
