Questão de Banco de Dados — MySQL — INSTITUTO AOCP 2024

Particionamento de tabelas no MySQL

Gabarito: letra B. Para otimizar consultas em uma tabela de pedidos com grande volume de dados, a estratégia mais apropriada é particionar a tabela por faixas de datas, pois isso permite que o MySQL acesse apenas as partições relevantes para a consulta, reduzindo drasticamente a quantidade de dados varridos. Essa técnica é especialmente eficaz quando as consultas filtram por um intervalo de datas, como é comum em sistemas de e-commerce.

O particionamento é uma técnica de otimização física que divide uma tabela lógica em segmentos menores, chamados partições, com base em um critério definido, como faixa de valores, lista ou hash. No MySQL, o particionamento por faixa (RANGE) é particularmente útil para dados temporais, pois cada partição pode armazenar um período específico (ex.: um mês, um trimestre). Quando uma consulta filtra por data, o otimizador pode realizar a poda de partições (partition pruning), lendo apenas as partições que contêm os dados solicitados, em vez de varrer a tabela inteira. Isso reduz o I/O e melhora o tempo de resposta, além de facilitar a manutenção, como arquivar partições antigas.

A escolha da estratégia de otimização depende do padrão de acesso aos dados. No cenário de e-commerce, as consultas mais comuns envolvem buscar pedidos por período (ex.: relatórios de vendas do último mês, análise de tendências). O particionamento por data alinha-se perfeitamente a esse padrão. Outras técnicas, como indexação, são úteis para acelerar buscas por valores específicos, mas não resolvem o problema de varrer grandes volumes de dados históricos. A desnormalização pode melhorar a leitura, mas aumenta a redundância e a complexidade de manutenção. Converter para MyISAM é uma regressão, pois esse mecanismo não suporta transações e é obsoleto. Funções de janela são recursos de consulta, não de armazenamento físico.

É importante entender que o particionamento não é uma solução universal. Ele deve ser planejado com base no padrão de consultas e na distribuição dos dados. No MySQL, o particionamento é suportado apenas em tabelas InnoDB e MyISAM, mas o InnoDB é o recomendado por oferecer suporte a transações e integridade referencial. Além disso, a chave de particionamento deve ser escolhida com cuidado: se as consultas não filtram pela coluna de particionamento, o particionamento pode até piorar o desempenho, pois o otimizador precisará acessar todas as partições.

A pegadinha desta questão está em distinguir as técnicas de otimização que atuam em níveis diferentes: índices e particionamento são estruturas físicas; desnormalização é uma alteração no modelo lógico; MyISAM é uma escolha de mecanismo de armazenamento; e funções de janela são recursos de consulta. A banca espera que o candidato identifique qual técnica ataca diretamente o problema de volume de dados com filtro por data.

Alternativa A — ❌ Incorreta

Criar índices agrupados em todas as colunas de chave estrangeira não é uma boa prática. Índices agrupados (clustered) no MySQL são implementados apenas no InnoDB, e a tabela só pode ter um índice agrupado (a chave primária). Criar índices em todas as FKs pode acelerar joins, mas não resolve o problema de varrer grandes volumes de dados por faixa de datas. Além disso, índices em excesso aumentam o custo de escrita e o espaço em disco. O correto seria criar índices seletivos nas colunas mais usadas em filtros e joins, não em todas as FKs.

Alternativa B — ✅ Correta ⟵ GABARITO

Particionar a tabela de pedidos por faixas de datas é a estratégia mais apropriada para o cenário descrito. Com o particionamento por RANGE na coluna de data, o MySQL pode realizar a poda de partições, lendo apenas as partições que contêm os dados do período consultado. Isso reduz drasticamente o I/O e melhora o desempenho das consultas que filtram por data, que são típicas em sistemas de e-commerce. Além disso, facilita a manutenção, como arquivar partições antigas.

Alternativa C — ❌ Incorreta

Converter todas as tabelas para o mecanismo de armazenamento MyISAM é uma regressão. O MyISAM não suporta transações (ACID), nem chaves estrangeiras, nem recuperação de falhas robusta. Embora tenha sido popular no passado, é inadequado para aplicações de e-commerce que exigem integridade e concorrência. O InnoDB é o mecanismo padrão e recomendado no MySQL 8, oferecendo suporte a transações, row-level locking e melhor desempenho em cargas de trabalho mistas.

Alternativa D — ❌ Incorreta

Desnormalizar o modelo de dados, combinando várias tabelas em uma única, pode melhorar a leitura em alguns casos, mas não é a estratégia mais apropriada para o cenário. A desnormalização introduz redundância, aumenta o risco de inconsistência e dificulta a manutenção. Em um sistema de e-commerce, onde há muitas escritas (novos pedidos, atualizações), a desnormalização pode piorar o desempenho geral. O particionamento é uma solução mais cirúrgica e menos invasiva.

Alternativa E — ❌ Incorreta

Utilizar o recurso de Janelas e Funções Analíticas para simplificar consultas complexas é uma técnica de consulta, não de otimização de armazenamento. Funções de janela (ex.: ROW_NUMBER, SUM OVER) são úteis para cálculos analíticos, mas não reduzem o volume de dados lidos do disco. Elas podem até aumentar o custo de processamento se aplicadas sobre grandes conjuntos de dados. A otimização de desempenho deve focar em reduzir o I/O, como faz o particionamento.

Gabarito: letra B