Em administração de banco de dados MySQL, os recursos disponíveis para auxiliar na identificação de problemas relacionados à lentidão em um aplicativo são:
- A)log de erros (Error log) e esquema de desempenho (performance schema);
Errada, porque o error log serve para registrar falhas e eventos do servidor, mas não é a ferramenta principal para identificar lentidão em aplicações.
- B)log de consultas lentas (slow query log) e esquema de desempenho (performance schema);
Certa, porque o slow query log evidencia consultas demoradas e o performance schema ajuda a diagnosticar gargalos e comportamento interno do servidor.
- C)esquema de desempenho (performance schema) e log binário (binary log);
Errada, porque o binary log é voltado para replicação e recuperação, não para análise direta de desempenho e lentidão.
- D)declaração GET DIAGNOSTICS e log de consultas lentas (slow query log);
Errada, porque GET DIAGNOSTICS é uma instrução para obter informações de diagnóstico em contexto de SQL/erros, mas não substitui ferramentas de análise de desempenho.
- E)log binário (binary log) e lista de índices desatualizados.
Errada, porque o binary log não é recurso de diagnóstico de lentidão e não existe essa associação com lista de índices desatualizados como ferramenta padrão do MySQL.
Gabarito: B
Quando o assunto é descobrir por que um aplicativo MySQL está lento, você precisa olhar para os recursos que realmente ajudam a enxergar consultas demoradas e o que o servidor está fazendo por trás das cortinas. Nesse ponto, dois aliados clássicos entram em cena: o slow query log e o performance schema. O primeiro registra consultas que ultrapassam um limite de tempo, ajudando a achar os “vilões” da lentidão. O segundo oferece uma visão bem mais detalhada do comportamento interno do servidor, com eventos, waits, uso de recursos e outros indicadores úteis para diagnóstico. O slow query log é quase um detector de consultas preguiçosas: ele mostra o que demorou demais e merece investigação. Já o performance schema funciona como um painel de instrumentos do MySQL, permitindo observar execução, contenção e gargalos. Em prova, isso costuma aparecer como a dupla ideal para troubleshooting de desempenho, especialmente quando a pergunta fala em identificar problemas relacionados à lentidão. Por isso o gabarito é a letra B. Ela reúne exatamente os recursos mais úteis para análise de performance e diagnóstico de lentidão. As outras opções misturam ferramentas voltadas a erro, replicação, auditoria ou diagnóstico de exceções, que não são a primeira escolha quando o foco é achar a causa da lentidão em aplicativos. Em resumo: para caçar consulta lenta e entender o comportamento do servidor, você mira no slow query log e no performance schema.