Um DBA necessita executar algumas ações para otimizar um servidor MySQL v8.Com relação à otimização para tipos BLOB, avalie se as afirmativas a seguir são verdadeiras (V) ou falsas (F).( ) Ao armazenar um BLOB grande contendo dados textuais, o analista deverá considerar compactá-lo primeiro e não deve usar esta técnica quando a tabela inteira estiver compactada por InnoDB ou MyISAM.( ) Para uma tabela com diversas colunas, afim de reduzir os requisitos de memória para consultas que não utilizam a coluna BLOB, o analista deverá considerar dividir a coluna BLOB em uma tabela separada e referenciá-la com uma consulta de junção quando necessário.( ) Como os requisitos de desempenho para recuperar e exibir um valor BLOB podem ser muito diferentes de outros tipos de dados, o analista deverá colocar a tabela específica do BLOB em um dispositivo de armazenamento diferente ou até mesmo em uma instância de banco de dados separada. Por exemplo, para recuperar um BLOB pode ser necessária uma grande leitura sequencial de disco, mais adequada a um disco rígido tradicional do que a um dispositivo SSD.As afirmativas são, respectivamente,
AV – V – V.
BV – F – F.
CF – V – F.
DF – V – V.
EF – F – F.
Revelar gabarito e comentário▾
GabaritoA — V – V – V.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Otimização de BLOB no MySQL
Gabarito: letra A. Todas as afirmativas são verdadeiras. A banca testa boas práticas de otimização para colunas BLOB no MySQL, como compressão seletiva, separação vertical de tabelas e considerações de armazenamento físico.
A questão aborda três técnicas comuns de otimização para colunas BLOB, que podem impactar significativamente o desempenho e o uso de recursos. Vamos analisar cada uma.
Afirmativa
V/F
Justificativa
1. Ao armazenar um BLOB grande contendo dados textuais, o analista deverá considerar compactá-lo primeiro e não deve usar esta técnica quando a tabela inteira estiver compactada por InnoDB ou MyISAM.
V
A compressão explícita de um BLOB reduz o espaço de armazenamento e a I/O, mas é redundante se a engine já comprime a tabela inteira. Comprimir sobre algo já comprimido não traz ganho e consome CPU desnecessariamente.
2. Para uma tabela com diversas colunas, a fim de reduzir os requisitos de memória para consultas que não utilizam a coluna BLOB, o analista deverá considerar dividir a coluna BLOB em uma tabela separada e referenciá-la com uma consulta de junção quando necessário.
V
Essa técnica de particionamento vertical isola colunas grandes (BLOB) em tabelas separadas. Consultas que não precisam do BLOB evitam ler esses dados, reduzindo I/O e uso de memória no buffer pool.
3. Como os requisitos de desempenho para recuperar e exibir um valor BLOB podem ser muito diferentes de outros tipos de dados, o analista deverá colocar a tabela específica do BLOB em um dispositivo de armazenamento diferente ou até mesmo em uma instância de banco de dados separada. Por exemplo, para recuperar um BLOB pode ser necessária uma grande leitura sequencial de disco, mais adequada a um disco rígido tradicional do que a um dispositivo SSD.
V
A leitura de BLOBs grandes é tipicamente sequencial e demanda largura de banda. Discos rígidos (HDs) tradicionais podem ser mais econômicos para armazenamento sequencial volumoso, enquanto SSDs são melhores para acesso aleatório. Separar a tabela de BLOB em um dispositivo otimizado para sequencial melhora o desempenho geral.
Afirmativa 1 — ✅ Verdadeira
A compactação de dados textuais armazenados em BLOB reduz o espaço em disco e a quantidade de dados transferidos. No entanto, se a tabela já utiliza compressão nativa do InnoDB (com ROW_FORMAT=COMPRESSED) ou do MyISAM (com PACK_KEYS ou compressão de página), comprimir novamente é redundante e desperdiça CPU. A prática correta é aplicar compressão apenas quando a engine não comprime a tabela inteira.
Afirmativa 2 — ✅ Verdadeira
Separar colunas BLOB em uma tabela própria é uma forma de particionamento vertical. Consultas que não acessam a coluna BLOB não precisam carregar esses dados pesados, reduzindo a memória necessária no buffer pool e a I/O. A junção (JOIN) é usada quando o BLOB é necessário, mantendo a flexibilidade. Essa técnica é recomendada pela documentação do MySQL para otimização de tabelas com colunas largas.
Afirmativa 3 — ✅ Verdadeira
BLOBs grandes exigem leitura sequencial intensiva. Discos rígidos tradicionais (HDs) oferecem boa taxa de transferência sequencial a baixo custo, sendo adequados para armazenamento de BLOBs. SSDs são superiores em acesso aleatório, mas podem ser menos eficientes para sequencial puro em alguns cenários. Além disso, separar a tabela de BLOB em um dispositivo diferente reduz a contenção de I/O com outras tabelas, melhorando o desempenho global.
PEGA ESSA DICA!
Na prática, a segunda afirmativa é uma técnica comum de otimização, mas deve ser balanceada com a complexidade adicional de joins. Avalie o perfil de consultas antes de aplicar.
Conclusão: Todas as afirmativas são verdadeiras (V-V-V). Portanto, a alternativa correta é a letra A.