Hypergraph Optimizer: o novo otimizador de JOINs do MySQL

Para decidir em que ordem executar os JOINs de uma consulta, o otimizador clássico do MySQL usa uma busca gulosa: ele monta o plano tabela por tabela, sempre escolhendo a próxima que parece mais barata naquele momento, sem reconsiderar a decisão depois. Isso funciona bem para consultas simples, mas em JOINs com muitas tabelas, subconsultas e condições de OUTER JOIN misturadas, essa abordagem pode deixar passar planos melhores. O Hypergraph Optimizer é um otimizador de junções alternativo, reescrito do zero, que representa a consulta como um grafo onde tabelas são nós e condições de junção são arestas — daí o nome — permitindo explorar uma gama muito maior de ordens de junção possíveis antes de escolher a mais barata.

Por que um otimizador novo

O otimizador de junções atual do MySQL existe, em sua essência, desde as primeiras versões do produto. Ele foi estendido ao longo dos anos para lidar com casos como subconsultas correlacionadas e junções externas, mas cada extensão virou mais uma regra especial encaixada em uma arquitetura que não foi pensada para isso. O Hypergraph Optimizer ataca o problema de outro jeito: qualquer combinação de tabelas, junções internas ou externas, e subconsultas é modelada uniformemente como um hipergrafo, e o otimizador busca nesse grafo o plano de menor custo sem as limitações estruturais do antigo algoritmo guloso.

Ativando para uma consulta

O Hypergraph Optimizer é controlado pela flag hypergraph_optimizer da variável optimizer_switch, e vem desligado por padrão. A forma mais segura de experimentá-lo é ativá-lo apenas para uma consulta específica, com um hint SET_VAR, o que facilita comparar o plano antigo com o novo lado a lado:

SELECT /*+ SET_VAR(optimizer_switch = 'hypergraph_optimizer=on') */
    p.id, c.nome, i.produto
FROM pedidos p
JOIN clientes c ON c.id = p.cliente_id
JOIN itens_pedido i ON i.pedido_id = p.id
WHERE c.cidade = 'São Paulo'
  AND p.status = 'pendente';

Para ativar durante toda a sessão, em vez de repetir o hint em cada consulta:

SET SESSION optimizer_switch = 'hypergraph_optimizer=on';

E para voltar ao otimizador clássico:

SET SESSION optimizer_switch = 'hypergraph_optimizer=off';

Lendo o plano com EXPLAIN FORMAT=TREE

O Hypergraph Optimizer representa planos internamente de um jeito diferente do otimizador clássico, e por isso não é compatível com o formato tabular tradicional do EXPLAIN. Pedir FORMAT=TRADITIONAL com o hypergraph ativo retorna um erro:

SET SESSION optimizer_switch = 'hypergraph_optimizer=on';

EXPLAIN FORMAT=TRADITIONAL
SELECT * FROM pedidos WHERE cliente_id = 42;

ERROR 3999 (HY000): The hypergraph optimizer does not yet support
'EXPLAIN with TRADITIONAL format'.

O formato suportado é o TREE, o mesmo usado por EXPLAIN ANALYZE:

EXPLAIN FORMAT=TREE
SELECT p.id, c.nome
FROM pedidos p
JOIN clientes c ON c.id = p.cliente_id
WHERE p.status = 'pendente';

-> Nested loop inner join  (cost=118.40 rows=45)
    -> Filter: (p.status = 'pendente')  (cost=58.20 rows=45)
        -> Table scan on p  (cost=58.20 rows=900)
    -> Single-row index lookup on c using PRIMARY (id=p.cliente_id)
        (cost=0.25 rows=1)

Comparar essa árvore com a gerada pelo otimizador clássico, para a mesma consulta, é a forma mais direta de ver se o hypergraph escolheu uma ordem de junção diferente — e, com EXPLAIN ANALYZE FORMAT=TREE, também comparar os tempos reais de execução de cada plano.

Limitações atuais

O Hypergraph Optimizer ainda está em desenvolvimento ativo e não é um substituto completo do otimizador clássico:

• A maioria dos hints de otimização (JOIN_ORDER, INDEX, NO_ICP etc.) ainda não é respeitada — a única exceção é STRAIGHT_JOIN, que continua funcionando normalmente.
• EXPLAIN FORMAT=TRADITIONAL não é suportado; só FORMAT=TREE funciona, e o formato JSON só é aceito na versão 2 do esquema.
• Para consultas simples ou com estimativas de linhas muito imprecisas, o otimizador clássico ainda pode, em alguns casos, escolher um plano melhor.

Quando vale testar

• Relatórios e consultas analíticas que juntam muitas tabelas (seis ou mais), onde a busca gulosa do otimizador clássico tende a deixar passar a melhor ordem de junção.
• Consultas com uma mistura complexa de JOIN, LEFT JOIN e subconsultas, que o planejador clássico só suporta através de regras especiais.
• Ambientes de teste e homologação, para comparar planos e reportar regressões antes de considerar habilitá-lo em produção.

Compatibilidade

A flag hypergraph_optimizer existe desde o MySQL 8.0.31 (outubro de 2022), inicialmente como recurso interno sem suporte oficial para uso em produção. A partir do MySQL 9.7 (2025), o Hypergraph Optimizer passou a estar disponível também na Community Edition, documentado oficialmente, mas ainda desligado por padrão e classificado como um recurso em evolução — vale testá-lo em um ambiente controlado antes de habilitá-lo de forma permanente. Builds que não incluem o recurso simplesmente ignoram ou rejeitam a tentativa de ativá-lo.

documentação oficial

Conclusão

O Hypergraph Optimizer não é só uma otimização incremental: é uma reescrita da forma como o MySQL decide a ordem dos JOINs, pensada para escalar melhor em consultas complexas que o algoritmo guloso clássico tem dificuldade em planejar bem. Ainda não é o padrão nem cobre todos os casos, mas já vale a pena ativá-lo em uma consulta pontual com o hint SET_VAR para comparar o plano gerado com o do otimizador atual.