No contexto de administração de banco de dados MySQL, ao planejar o armazenamento de tabelas e índices, considerando otimizar a alocação de espaço e melhorar o desempenho do sistema, é recomendado:
- A)definir tamanhos de página menores para todas as tabelas e índices para reduzir a fragmentação;
Errada, porque reduzir tamanho de página para tudo não é recomendação geral e pode até prejudicar o desempenho por aumentar overhead e fragmentação lógica.
- B)utilizar a compactação de tabelas para economizar espaço em disco, independentemente do tipo de dado;
Errada, porque compactação depende do tipo de dado e do cenário de uso, não sendo uma solução universal para economizar espaço sem efeitos colaterais.
- C)utilizar partições para separar dados históricos de dados recentes em tabelas com alta taxa de inserção;
Certa, pois particionar por critério como tempo é uma estratégia adequada para separar dados recentes de históricos em tabelas com alta inserção.
- D)armazenar todos os índices em um disco (SSD) e as tabelas de dados em um disco rígido tradicional (HDD) para equilibrar o desempenho e o custo;
Errada, porque a distribuição de tabelas e índices em discos diferentes não é uma recomendação padrão dessa forma e depende da arquitetura, não de uma regra fixa.
- E)utilizar o mecanismo de armazenamento MyISAM para todas as tabelas, pois ele oferece melhor desempenho em leitura e é compatível com a propriedade ACID.
Errada, porque o MyISAM não oferece compatibilidade com ACID; quem é associado a transações e integridade é o InnoDB.
Gabarito: C
Quando o assunto é MySQL, você precisa pensar em duas coisas ao mesmo tempo: espaço e desempenho. Em tabelas que recebem muitas inserções, atualizar e reorganizar tudo o tempo inteiro pode virar um pequeno caos, então faz sentido separar o que muda muito do que é mais antigo e pouco consultado. Isso ajuda a manter o acesso mais organizado e reduz trabalho desnecessário nas operações do dia a dia. A ideia de particionamento é justamente essa: dividir uma tabela grande em partes menores, seguindo um critério lógico, como faixa de datas. Assim, dados históricos podem ficar em uma partição e os dados recentes em outra, o que melhora a manutenção e pode acelerar consultas e rotinas como purge, backup e arquivamento. No contexto da questão, a alternativa C está correta porque separar dados históricos de dados recentes em tabelas com alta taxa de inserção é uma prática recomendada quando se quer otimizar armazenamento e desempenho. Em cenários de crescimento contínuo, isso ajuda a reduzir impacto sobre as partes mais acessadas e facilita a gestão do volume de dados. As demais alternativas misturam conceitos de forma imprecisa ou trazem afirmações erradas sobre MySQL. Em prova, a banca costuma explorar justamente essas generalizações bonitas, mas perigosas. Particionamento não é milagre, mas é uma solução bem coerente quando há muitos dados, muita escrita e necessidade de organizar melhor o armazenamento.