Artigos Banco de Dados Conhecendo as engines do MySQL
Por que eu devo ler este artigo:O MySQL é um banco comumente utilizado por desenvolvedores, pois possui licença community, baixa complexidade, facilidade de instalação e é muito comum em provedores web de todo o mundo. Isso faz com que sua utilização seja instantânea, mas também faz com que não sejam observadas configurações de utilização de acordo com o software e o ambiente. Neste artigo trataremos da análise das engines, configuração e melhor forma de utilização dos principais tipos de engines existentes no MySQL. As engines, típicas do MySQL, são um ponto forte do SGBD e fazem com que ele apresente uma grande vantagem quando comparado a bancos de grande porte, como Oracle, SQL Server e DB2.

Explicando de maneira bem simples, as engines são tipos de tabelas que fazem parte do MySQL. Para utilizarmos esse recurso, nada se faz necessário na instalação, que já contempla diversos tipos diferentes a serem configurados como parâmetros na hora da criação de uma tabela. É importante citar que não estamos limitados às engines que já vêm com a instalação do MySQL, também podemos adquirir novas e instalá-las posteriormente.

A vantagem das engines são as diferentes características de cada uma, o que afeta a velocidade de leitura, escrita, transações, integridade, forma de armazenamento e escrita no log. Portanto, fica claro ver que a escolha de qual engine usar afeta diretamente o desempenho das consultas realizadas, por exemplo.

Neste artigo veremos o que são as engines, suas principais características, seus pontos fortes e fracos e em que ambientes devemos utilizar cada tipo a fim de aumentar o desempenho do banco de dados MySQL. Veremos também como verificar quais já estão instaladas em seu servidor e como criar tabelas utilizando esse recurso. Por último, realizaremos um teste de desempenho nas tabelas construídas.

As engines podem ser divididas em dois grupos: transacionais e não transacionais. Para entendermos melhor os dois grupos, precisamos entender o conceito de transação e o que há por trás dele. Para atender uma transação, o banco de dados precisa respeitar o acrônimo ACID, que significa:

  • Atomicidade: toda transação executada por um banco deve ser atômica. Ou todas as operações funcionam ou nenhuma delas é realizada. Tecnicamente falando, caso haja alguma falha em qualquer ponto da transação, é efetuado um ROLLBACK e nada é alterado;
  • Consistência: a execução de uma transação deve permitir um estado consistente do banco de dados;
  • Isolamento: uma transação não pode interromper outra transação em curso;
  • Durabilidade: após a execução de uma transação, os dados devem ser salvos e mantidos no banco de dados, mesmo que haja qualquer tipo de falha posterior. Tecnicamente falando, após a execução de todas as operações, a transação será concluída com um COMMIT e os dados serão salvos no banco de dados.

Entendendo uma transação

Na Figura 1, temos um cenário inicial, onde o correntista A possui R$10.000,00 em sua conta e o correntista B possui R$ 2.000,00 em sua conta. O objetivo é que o correntista A transfira R$ 2.000,00 para o correntista B. Podemos considerar como uma transação a transferência como um todo, enquanto que as operações de retirada da conta A e depósito na conta B são operações separadas que estão presentes nessa transação.

Transferência bancária com controle de transação com ACID

Figura 1. Transferência bancária com controle de transação com ACID

Na Figura 2, temos a mesma transação, onde precisamos retirar R$2.000,00 da conta A e transferir para a conta B. Observe que entre as duas operações ocorre uma falha de hardware, e o resultado final é de menos R$ 2.000,00 na conta A e o mesmo saldo na conta B.

Ocorre apenas a execução da primeira operação

Figura 2. Ocorre apenas a execução da primeira operação.

O ocorrido foi a falta da atomicidade, ou seja, não houve uma transação atômica. As operações foram executadas isoladamente, e, após a execução da primeira, a falha de hardware não deixou que a segunda fosse executada. Caso houvesse a mesma falha de hardware no cenário da Figura 1, o MySQL abortaria toda a transação, e, por consequência, nenhuma quantia seria retirada da conta A e nenhuma quantia seria depositada na conta B, atendendo ao conceito de atomicidade.

Outro cenário muito comum onde as transações são indispensáveis ocorre em empresas que pos ...

Quer ler esse conteúdo completo? Tenha acesso completo