Você sabe o que são as Storage Engines do MySQL?
No seguinte artigo, Danielle Monteiro apresenta as Storage Engines, componentes do MySQL que manipulam as operações SQL para diferentes tipos de tabelas.

Nas últimas semanas eu venho falando muito do PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →, um banco de dados que eu adoro! Mas o combinado é que conversaríamos sobre os três bancos de dados open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → e relacionais do Azure↳Azure76 conteúdosDeploy de Azure Stream Analytics job com CI/CD usando Azure PipelinesDevSecOps · mai 2019Azure – Como criar uma base de dados SQL no Microsoft Azure pronta para ser utilizadaData · abr 2019Azure Static Web Apps com Vue.js e Visual Studio CodeDevSecOps · out 2023Ver tudo em DevSecOps → (PostgreSQL, MySQL e MariaDB). Por isso, hoje é dia de falar sobre o MySQL.
Todas as vezes que eu o utilizei foi com ressalvas, mas preciso confessar que é um banco de dados extremamente poderoso e com uma história fantástica!
Antes que alguém me questione, ou faça uma piada: ele pode ser usado sem o PHP. Aliás, acho esse casamento perfeito, e me arrisco a dizer que o MySQL faz parte do “ecossistema do PHP”. Acreditem em mim – ele é muito poderoso e seu uso vai muito além de páginas web.
Um pouco da história
A MySQL AB (empresa dona do MySQL) foi vendida para a Sun por um 1 bilhão de dólares, um valor impensado naquela época! Posteriormente, a Sun foi vendida para a Oracle e sendo assim, hoje o MySQL é um produto da Oracle.
A Oracle mantém duas versões do MySQL: uma gratuita e uma paga (que inclui serviços como suporte e ferramentas extras).
Se você optar por instalar a versão gratuita do MySQL nos seus servidores, é indispensável estar atento às condições de uso explicadas na licença GPL.
Quanto à versão gratuita, ela é chamada de community, e pode ser baixada neste link.
Esse artigo nasceu porque (na minha opinião) o que mais diferencia o MySQL dos outros SGBDs, é a possibilidade de escolher a Storage Engine. Essa liberdade nos dá a responsabilidade de escolher a opção certa para cada necessidade de negócio.
A flexibilidade do MySQL permite que ele seja uma opção interessante para trabalhar bem em ambientes muito diferentes e complexos. Ao mesmo tempo, ele pode potencializar aplicações embarcadas, DW, indexação de conteúdo e software de prateleira, sistemas redundantes e altamente disponíveis, processamento de transação on-line (OLTP) e muito mais. Ou seja, a utilização do MySQL vai muito além do PHP (repetindo para fixar).
Storage Engine
Para acabar o mistério, as Storage Engines são componentes do MySQL que manipulam as operações SQL para diferentes tipos de tabelas – simples assim!
Achei essa definição das Storge Engine na web e curti. Por isso, resolvi transcrevê-la com o objetivo de deixar o conceito o mais claro possível:
“Como os diversos sistemas de arquivo disponíveis para GNU/ Linux, cada storage engine possui seus próprios benefícios e desvantagens. O servidor comunica-se com elas através da API da storage engine. Essa interface esconde diferenças entre as SE e as tornam amplamente transparentes na camada de consulta. A API contém várias funções de baixo nível que realiza operações como “iniciar uma transação” ou “trazer a linha”. As storage engines não interpretam SQL nem se comunicam umas com as outras; elas simplesmente respondem às requisições do servidor.”
Ao criar uma tabela, o DBA ou desenvolvedor pode escolher qual a storage engine mais adequada. A possibilidade de escolha da storage engine nos permite extrair o melhor do MySQL, desde que escolhamos a opção certa para a necessidade da aplicação – como armazenamento de dados, processamento de transações ou situações de alta disponibilidade – enquanto aproveitam a vantagem de utilizar um conjunto de interfaces e serviços independentes de qualquer storage engine.
Se as alterações nos aplicativos ocasionarem alteração da storage engine, não serão necessárias alterações significativas no seu código para que as coisas funcionem. A arquitetura do servidor MySQL protege o aplicativo da complexidade da storage engine, apresentando uma API consistente e fácil de usar.
Quais Storage Engines tenho disponíveis?
Para começar, você pode verificar quais SE (= Storage Engine) seu servidor suporta, usando o comando SHOW ENGINES. O valor da coluna Support indica se a SE pode ser usada.
Atualmente, a InnoDB é um SE padrão do MySQL, pois equilibra alta confiabilidade e alto desempenho. Se você criar uma tabela no MySQL sem especificar a SE, a InnoDB será usada.
As características legais da InnoDB, são:
- Suas operações DML possuem suporte para as propriedades ACID, com transações que incluem recursos de confirmação, reversão e recuperação de falhas para proteger os dados.
- Bloqueio em nível de linha e leituras consistentes (no estilo Oracle) aumentam a simultaneidade e o desempenho para uma quantidade grande de usuários.
- As tabelas organizam seus dados no disco para otimizar as consultas com base nas chaves primárias. Cada tabela possui um índice cluster na chave primária que organiza os dados para minimizar o I/O em algumas consultas.
- Para manter a integridade referencial, o InnoDB suporta FOREIGN KEY. Ou seja, inserções, atualizações e exclusões são verificadas para garantir que não resultem em inconsistências em diferentes tabelas.
Existem diversas SE e eu não tenho a pretensão de abordar todas, mas abaixo segue um breve resumo daquelas que eu acho bem importantes:
- MyISAM: esta SE tem bloqueio no nível de tabela, bom desempenho para cargas em batch e posteriores leituras.
- Memory: armazena todos os dados na memória para acesso rápido em ambientes que exigem pesquisas rápidas de dados não críticos. Ou seja, use para cache.
- CSV: suas tabelas são realmente arquivos de texto com valores separados por vírgula. Esta SE permite importar ou baixar dados no formato CSV para trocar dados com scripts e aplicativos que leem e escrevem no mesmo formato. Cuidado com o fato das tabelas criadas com esta SE não serem indexadas, por isso, você normalmente manterá os dados nas tabelas criadas com InnoDB durante a operação normal, e só usará tabelas CSV durante o estágio de importação ou exportação.
- Archive: tabelas criadas com esta SE são compactas e não indexadas e destinam-se a armazenar e recuperar grandes quantidades de informações históricas, arquivadas ou de auditoria de segurança raramente referenciadas.
Para resumir, adorei a tabela que existe na documentação oficial do MySQL, por isso trouxe ela para o artigo, de modo que vocês a utilizem para decidir qual a melhor SE de acordo com suas necessidades:

E no Azure?
Falamos bastante das SE, mas quais estão disponíveis no serviço MySQL do Azure? Esse é um aspecto que você precisa levar em consideração. E eu fiquei bem feliz de testar as SE e descobrir que temos algumas opções. Não estão disponíveis a Archive e MyISAM (se você precisar desta storage engine, use MRG_MYISAM).
Conclusão
O MySQL é um dos bancos de dados mais usados no mundo. Pioneiro, flexível e com uma comunidade apaixonada!
Vale a pena conhecê-lo e utilizá-lo – sempre respeitando a versão e suas limitações de uso. Se você irá instalar o MySQL no seu servidor, ou vai criar uma VM no Azure, você tem diversas possibilidades de escolha de SE.
Analise seus requisitos e escolha a SE correta (tanto se optou instalar o MySQL, ou mesmo o Azure).
Aguardem e não percam! No próximo artigo mostrarei como criar um Servidor MySQL no Azure e conversaremos sobre as características, preços, utilização, administração e outros itens importantes.
Treinamentos
Para quem se interessa em fazer treinamentos de MySQL, eu indico os treinamentos da Nerv Informática. O instrutor é o Ricardo Portilho, que é a minha referência em MySQL e MariaDB.







