Questão de Banco de Dados — Otimização (Tuning) em Banco de Dados — INSTITUTO AOCP 2023

Otimização de consultas no MySQL: otimizador, índices e estratégias de junção

Gabarito: letra A — corretos apenas os itens I e III. O MySQL emprega um otimizador baseado em custo (item I) e a função STRAIGHT_JOIN de fato força a ordem de junção das tabelas conforme listadas na cláusula FROM (item III). Os itens II e IV estão incorretos: o índice FULLTEXT não é adequado para buscas comuns em colunas (é específico para texto completo) e a otimização de subqueries não garante performance superior à de um JOIN equivalente — na prática, muitas vezes ocorre o oposto.

A otimização de consultas (tuning) é o processo pelo qual o SGBD escolhe uma estratégia de execução — o chamado plano de consulta — para recuperar os resultados. O objetivo central é minimizar o tempo de resposta e obter ganho de desempenho, mas é importante entender que o termo "otimização" é, na prática, um exagero: o otimizador não garante o plano ótimo absoluto, apenas uma estratégia razoavelmente eficiente. No MySQL, esse processo é conduzido por um otimizador baseado em custo, que estima o custo de diferentes planos de execução (considerando estatísticas como cardinalidade, distribuição de dados, uso de CPU e E/S) e escolhe o mais barato. Isso contrasta com otimizadores puramente baseados em regras heurísticas, que aplicam transformações fixas sem avaliar custos.

Os índices são a ferramenta mais conhecida de otimização. Eles aceleram buscas evitando varreduras completas (full table scan), mas têm custos: pioram a performance de escritas (INSERT, UPDATE, DELETE), consomem espaço extra e exigem manutenção. Existem vários tipos de índice, cada um com finalidade específica. O índice FULLTEXT, por exemplo, é projetado para buscas em texto completo — como encontrar palavras ou frases em grandes volumes de texto — e não para operações comuns de busca em colunas, que são melhor atendidas por índices B-tree ou hash. Usar FULLTEXT para buscas comuns seria inadequado e ineficiente.

A ordem de junção das tabelas é uma decisão crítica para o desempenho. O otimizador normalmente decide a melhor ordem com base em custos, mas o MySQL oferece a função STRAIGHT_JOIN para forçar a junção na ordem exata em que as tabelas aparecem na cláusula FROM. Isso é útil quando o DBA sabe que a ordem escolhida pelo otimizador é subótima. Já a relação entre subqueries e JOIN é um ponto delicado: não há regra absoluta de que subqueries otimizadas sejam sempre melhores. Em muitas versões do MySQL, subqueries correlacionadas podem ser menos eficientes que JOINs equivalentes, e o otimizador frequentemente reescreve subqueries como JOINs internamente. A performance depende do caso concreto, das estatísticas e da versão do SGBD.

A pegadinha desta questão está em dois pontos: (1) associar FULLTEXT a buscas comuns, quando ele é específico para texto completo; e (2) afirmar que subqueries otimizadas são sempre superiores a JOINs, quando a realidade é que a performance varia e muitas vezes o JOIN é mais eficiente. Guarde essas duas distinções — são exatamente elas que separam as alternativas.

Item I — ✅ Correto

O MySQL utiliza um otimizador baseado em custo. Isso é fato: o otimizador estima o custo de diferentes planos de execução (com base em estatísticas como cardinalidade, distribuição de dados, uso de CPU e E/S) e escolhe o plano com menor custo estimado. O item está correto.

Item II — ❌ Incorreto

O índice FULLTEXT é adequado para operações de busca em texto completo, mas não para operações comuns de busca em colunas. Para buscas comuns (igualdade, faixa, prefixo), os índices apropriados são B-tree ou hash. O FULLTEXT é especializado em busca textual (palavras, frases, relevância) e usá-lo para buscas comuns seria inadequado. O erro está em afirmar que ele serve para ambos os casos.

Item III — ✅ Correto

A função STRAIGHT_JOIN força o MySQL a juntar as tabelas na ordem exata em que são listadas na cláusula FROM. Isso é uma funcionalidade documentada do MySQL, usada para sobrepor a decisão do otimizador quando o DBA sabe que a ordem natural é mais eficiente. O item está correto.

Item IV — ❌ Incorreto

A afirmação de que a otimização de subqueries "sempre" resulta em melhor performance que JOINs equivalentes é falsa. Não há garantia de que subqueries sejam sempre superiores; na prática, muitas vezes o JOIN é mais eficiente, especialmente em versões mais antigas do MySQL, onde subqueries correlacionadas eram notoriamente lentas. O otimizador frequentemente reescreve subqueries como JOINs internamente, o que demonstra que não há superioridade inerente. O erro está na palavra "sempre".

Conclusão: corretos apenas os itens I e III, portanto a alternativa correta é a letra A.

Gabarito: letra A