MySQL na Prática – Parte IV: Transações, Logs e Performance Schema

Depois de explorarmos as Procedures, Views e Triggers, chegamos ao nível em que o DBA pensa como o próprio mecanismo do MySQL.
Nesta quarta parte, o foco é controle, auditoria e diagnóstico — fundamentos que garantem consistência, rastreabilidade e desempenho mensurável.
Esses tópicos são a espinha dorsal das provas avançadas e das entrevistas de administradores de banco de dados.

Transações: a base da consistência

Transações são conjuntos de operações que devem ser executadas como uma unidade atômica — ou tudo é confirmado (commit), ou tudo é desfeito (rollback).
O MySQL implementa transações principalmente na engine InnoDB, que segue o modelo ACID (Atomicidade, Consistência, Isolamento e Durabilidade).

💡 Dica: use sempre START TRANSACTION, COMMIT e ROLLBACK em testes práticos.

START TRANSACTION;

UPDATE contas SET saldo = saldo – 100 WHERE id = 1;

UPDATE contas SET saldo = saldo + 100 WHERE id = 2;

COMMIT;

Se ocorrer um erro no meio do processo, um ROLLBACK; devolve o banco ao estado anterior — exatamente o tipo de detalhe que as bancas adoram cobrar.

Logs: rastreabilidade e auditoria

Os logs do MySQL registram cada etapa das operações do servidor e são indispensáveis para recuperação de falhas e auditorias.
Os principais são:

⚠️ Atenção: Bancas frequentemente perguntam a diferença entre General Log e Binary Log.
O primeiro grava todas as consultas; o segundo, apenas operações que alteram dados e são replicáveis.

Performance Schema: medindo o invisível

O Performance Schema é uma estrutura interna de monitoramento que coleta métricas sobre o comportamento do servidor.
Ele não é uma view, mas sim um subsistema de instrumentação que permite medir consumo de CPU, tempo de execução de queries e gargalos de I/O.

💡 Dica: para ativá-lo, verifique se a variável performance_schema está habilitada (ON).
As views como events_statements_summary_by_digest e threads ajudam a identificar consultas lentas e sessões com alto custo.

Questão 1 – Transações e ACID 

Em uma transação do MySQL, se o comando COMMIT não for executado, as alterações permanecem salvas permanentemente no banco.

A) Certo
B) Errado

✅ Comentário: Errado.
Sem COMMIT, as alterações ficam apenas na memória de transação e são descartadas ao fim da sessão ou com ROLLBACK.
Essa característica garante a atomicidade, um dos pilares do modelo ACID. Por padrão o MYSQL tem a opção do AUTOCOMMIT que pode ser desabilitada. Mas o COMMIT sempre é necessário ou explicitamente ou implicitamente.

Questão 2 – Logs e Auditoria 

O Binary Log é usado apenas para registrar consultas SQL executadas, sem relevância para backup ou replicação.

A) Certo
B) Errado

✅ Comentário: Errado.
O Binary Log é essencial para replicação e recuperação ponto a ponto (point-in-time recovery).
Ele grava toda alteração de dados, permitindo reconstruir o estado do banco até um momento anterior à falha.

Conclusão

Transações, Logs e o Performance Schema representam o coração técnico da administração do MySQL.
Dominar esses elementos é entender como o servidor pensa e reage diante de falhas e sobrecargas.
Mais do que decorar comandos, o verdadeiro profissional aprende a ler o que o banco “fala” — e isso é o que o diferencia nas provas e na prática.