Desde a versão 5.5 do MySQL o storage engine InnoDB vem configurado “de fábrica” como padrão.

O InnoDB é um storage engine transacional, 100% ACID, estável e robusto, e, inteiramente, grátis. Reconhecidamente, fez progressos notáveis desde o MySQL 4.x. Com destaques para as melhorias implementadas nas versões: 5.1, 5.5, 5.6, e, recentemente na 5.7.

O fato de o InnoDB vir de fábrica como padrão, nada nos impede de criarmos tabelas (ou alterarmos) utilizando a opção ENGINE, para que estas reflitam o storage engine que mais nos atende.

Os bancos de dados relacionais tradicionais, não utilizam o conceito de storage engine (tipo de tabela). Isto é uma inovação, e um mérito, do MySQL. Alguns acham que é uma falha, um bug. Mas, é uma poderosa funcionalidade (feature) muito bem vinda.

Declarar a morte do MyISAM é, em certa medida, declarar a morte de uma das características mais empolgantes do MySQL: o Storage Engine (motor de armazenamento).

É fato que a maioria das aplicações, ou em termos de banco de dados, a maioria das tabelas serão do tipo transacional, portanto InnoDB. Mas, há muito espaço para o MyISAM. E duvido, que estejamos presenciando a morte do MyISAM.

Gosto muito de compartilhar o exemplo do Zabbix, que é uma ferramenta excepcional de monitoramento. Certa vez, fiz uma manutenção em uma tabela de 700 gigas. Apenas alterando o Engine de InnoDB para MyISAM,  o tamanho despencou para menos de 100 gigas. Pare e pense, se uma captura de monitoramento de servidor deixar de ser salva/registrada, isso afetará o negócio da empresa? Por que usar transação??

MyISAM pode ser utilizado de forma, digamos pouco nobre, para armazenar dados que podem sofrer de completude, ausência, redundância, e integridade. Mas, não pode deixar de ser, altamente, performático.

Entre MyISAM e InnoDB, qual deve ser escolhido? É mais simples do que parece, basta perguntar para suas entidades e/ou tabelas:

• Transação: Se os dados precisam estar protegidos e orquestrados por uma transação, InnoDB.
• Integridade Referencial (chave estrangeira): Se jamais será utilizado integridade referencial, MyISAM.
• Granularidade: travamentos a nível de linha (locks), e, leituras sem “locks”, InnoDB.
• Performance: ÜberSpeed! Alta performance em leituras e escritas, definitivamente, MyISAM.
• Recuperação automática: Quando houver algum problema em páginas de dados ou índices, uma recuperação online e rápida é bem-vinda, InnoDB.
• Footprint (espaço em disco): Cada linha do Innodb ocupa, pelo menos 1K. Imagine se voce tem um punhando de tabelas com menos de 500 bytes de comprimento? Se footprint é um requerimento: MyISAM.

O fato é que podemos ficar fazendo esse jogo de Spy vs Spy o artigo inteiro. InnoDB e MyISAM são diferentes animais. Para usos e casos diferentes.

Eu, prefiro adotar uma abordagem menos apaixonada e objetiva:

InnoDB: todas as tabelas transacionais, absolutamente todas!

MyISAM: Todas as tabelas não transacionais, tais como:

• Sumarizadas
• Log
• Ingestão de dados para futuro processamento e consumo
• Intermediárias (preparação para relatórios)
• Dashboards
• Filas
• Staging (ETL)

Portanto, eu escolho MyISAM se a maioria dos seguintes requisitos forem atendidos: pode ser reconstruída, não é a fonte primária dos dados, uso temporário ou dinâmico (staging), processo de ETL, alguma falta de dado e/ou integridade é aceitável.

A verdade é que existe muito espaço para MyISAM, e, não veremos sua morte tão cedo. Pode apagar as velas!