Nos dois primeiros post desta sequência, mostrei um pouco sobre o MySQL Hypergraph Optimizer.
No blog 1:
Mostrei a todos o porque não conseguimos ativar a variável via SET em ambientes padrões, mesmo utilizando o MySQL 8.0.43.
No blog 2:
Mostrei o otimizador clássico em ação, utilizando JOINs mais complexos mostrando teoricamente onde o Hypergraph deveria fazer a diferença.
E para finalizarmos esta série, sairemos do cenário “real”.
Aqui, o objetivo será direto:
“Executar as mesmas queries, em cima dos mesmo dados, porém dentro do MySQL Debug, com o Hypergraph efetivamente ativo”.
É neste ponto que conseguimos enxergar o que não aparece em Produção.
O ambiente utilizado (Debug).
Para este post, utilizei o ambiente totalmente isolado, criado especialmente para usarmos o otimizador.
- MySQL 8.0.43 (Debug).
- Pacote (mysql-community-server-debug).
- MySQL rodando 3310.
Para deixarmos claro.
MySQL Debug não deve, em hipótese alguma, ser usado em Produção.
Ele existe exclusivamente para estudos internos, validações de código e diagnóstico avançado.
Ativando o Hypergraph Optimizer (finalmente).
Iniciaremos o gran finale deste série, abaixo iremos reproduzir todos os processos feitos nos blogs anteriores que não funcionarão, por conta da BUILD não ser Debug.
Então, vamos confirmando nossa versão do banco:
Agora, que vimos acima o uso do MySQL Debug… vamos começar a brincadeira.
Ativando nosso Hypergraph.
Podemos notar que, mesmo utilizando o MySQL Debug existe ainda um “warning” mediante a utilização desta feature.
Executando as mesmas queries anteriores.
Para mantermos total coerência ao post anterior, executei exatamente as mesma queries com JOINs múltiplos, por exemplo:
|
1 2 3 |
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; |
O objetivo aqui não era buscar “milagres” de performance, mas sim observar:
- Como o plano é construído
- Como os custos são avaliados
- Como as decisões diferem do otimizador clássico
Com o hypergraph optimizer, o MySQL passou a escolher a tabela motora com base no custo global de JOINs, separando os predicados independentes e produzindo estimativas de cardinalidade mais estáveis, ainda que com maior overhand de planejamento em builds de debug.
Abaixo, o que consultamos anteriormente no post 2:
O que muda com o Hypergraph ativo.
Mesmo que o resultado final da query seja o mesmo, algumas diferenças ficam claras quando analisamos os planos e comportamentos internos.
- O otimizador passa a considerar combinações de JOIN de forma mais global.
- A ordem escrita no SQL perde um pouco da influência.
- O espaço de busca de planos é maior.
- Algumas decisões deixam de ser puramente heurísticas.
Em outras palavras:
E isto, é o tipo de comportamento que não aparece em EXPLAIN tradicionais em Produção, e que só vemos via MySQL Debug.
O que ainda não muda…. (e porque?).
Um ponto importante de reforçar:
- O Hypergraph Optimizer não ignora estatísticas
- Cardinalidade errada continua sendo um problema
- Índices ruins continuam impactando o plano
Ou seja, o Hypergraph não corrige problemas de modelagem ou estatística.
Ele apenas oferece um modelo mais poderoso de avaliação de planos.
Porque isto não está exposto em Produção?
Depois de realizar toda parte conceitual, mais a parte prática.
Vemos que:
- O hypergraph aumenta o custo computacional das otimizações.
- Exige mais validações internas.
Hoje, serve muito mais como:
- Base de evolução do otimizador clássico.
- Ferramenta essencial para o HeatWave.
- E fundamento para futuras versões do MySQL.
E não como algo a ser “ligado” ou “desligado” como uma flag em Produção.
Conclusão.
Referências.
Explicação do código do Hypergraph Join Optimizer
MySQL Hypergraph Optimizer -> What, Why and How
