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,
- A)V – V – V.
Correta, porque as três afirmações refletem práticas válidas de otimização para BLOB no MySQL.
- B)V – F – F.
Incorreta, pois a primeira e a segunda afirmativas são verdadeiras.
- C)F – V – F.
Incorreta, porque a segunda e a terceira afirmativas também estão corretas.
- D)F – V – V.
Incorreta, já que a primeira afirmativa não é falsa e as demais tampouco.
- E)F – F – F.
Incorreta, porque nenhuma das três afirmativas é falsa.
Gabarito: A
Quando a coluna é do tipo BLOB, o problema não é só armazenamento, mas também custo de leitura, memória e I/O. Em MySQL, faz sentido tratar BLOB grande como algo especial: se ele contém texto e for possível, compactar antes pode reduzir espaço e tráfego. A própria documentação do MySQL recomenda considerar compressão do dado, mas com cuidado para não misturar essa técnica com tabelas já compactadas por mecanismos como InnoDB ou MyISAM, porque aí a economia adicional costuma ser pequena ou inviável. Outro ponto clássico é separar o BLOB em outra tabela quando ele não é usado em todas as consultas. Assim, as consultas “normais” não carregam esse peso desnecessário, reduzindo uso de memória e custo de execução. Quando precisar do conteúdo, você faz um JOIN ou busca sob demanda. Isso é arquitetura básica de desempenho: não carregar o “trambolho” quando você só queria o cadastro simples. A terceira afirmativa também está alinhada com boas práticas de otimização: BLOB pode ter padrão de acesso bem diferente do restante da tabela, então pode ser útil colocá-lo em outro dispositivo ou até em outra instância. O texto da questão até cita leitura sequencial grande, algo que pode ser melhor atendido por armazenamento específico, dependendo do cenário. Ou seja, a banca cobrou um raciocínio prático de tuning, bem em linha com recomendações técnicas do próprio MySQL. Por isso o gabarito é A, com todas as afirmativas verdadeiras. A questão explora três medidas de otimização para BLOB: compactação, separação em tabela própria e isolamento físico/logístico do armazenamento.