Como você escolhe um mecanismo de banco de dados MySQL

Em particular, como você escolhe entre MyISAM e InnoDB, quando nenhum deles está faltando um recurso necessário (por exemplo, você não precisa de chaves estrangeiras).

Sempre se trata de tentar os dois e medir? Ou existem boas regras práticas sobre o número e a frequência de leituras versus gravações e outras medidas como essa? O tamanho da tabela tem algum efeito sobre a escolha típica?

A resposta é que você deve sempre medir, de preferência com seus próprios dados e carga de trabalho, se possível.

Como os padrões de acesso a dados podem variar muito de aplicativo para aplicativo, é difícil dizer e com toda a probabilidade impossível determinar o "melhor" mecanismo de armazenamento para todas as cargas de trabalho.

No entanto, há desenvolvimentos muito encorajadores no espaço MySQL, tendo participado do MySQLConf / Percona Performance Conf na semana passada.

Alguns dos mecanismos de armazenamento alternativos:

1. XtraDB (fork do InnoDB)
2. Plugin InnoDB
3. PBXT
4. TokuDB

Além disso, a Percona, o Google etc. contribuíram com patches que ajudam muito no desempenho do InnoDB. Pessoalmente, eu executo uma compilação OurDelta. Funciona muito bem para mim e incentivo a verificação das versões OurDelta e Percona.

Se for apenas um sistema simples de armazenamento / relatório, utilizo o MyISAM para o desempenho bruto.

Eu usaria o InnoDB se estivesse preocupado com vários acessos simultâneos com muitas gravações, para aproveitar o bloqueio no nível de linha.

Há um bom número de benchmarks por aí para diferentes mecanismos de banco de dados MySQL. Há um decente comparando MyISAM, InnoDB e Falcon no Percona MySQL Performance Blog , veja aqui .

Outra coisa a considerar entre os dois mecanismos mencionados acima (MyISAM e InnoDB) são suas abordagens ao bloqueio. O MyISAM executa o bloqueio de tabela, enquanto o InnoDB executa o bloqueio de linhas. Há uma variedade de coisas a considerar, não apenas números de desempenho absolutos.

Existem recursos que você achará muito úteis, por razões operacionais, mesmo que seu aplicativo não exija absolutamente:

• O InnoDB possui MVCC, o que significa que você pode fazer backups consistentes sem bloqueio
• O InnoDB possui recuperação automática, o que significa que não há operações demoradas REPAIR TABLE após um desligamento imundo
• Com o InnoDB, os leitores nunca bloqueiam escritores e vice-versa, o que significa (geralmente falando) maior simultaneidade (embora isso não deva significar melhor desempenho no caso geral)
• O InnoDB agrupa suas linhas na chave primária, o que PODE significar menos operações de IO para operações de leitura SE a chave primária foi escolhida suficientemente bem.

Portanto, apesar das restrições de chave estrangeira, você provavelmente deseja usar o InnoDB de qualquer maneira.

é claro que se trata de ServerFault, não Stack Overflow, portanto a resposta correta é:

• Você sempre deve usar o mecanismo escolhido pelos desenvolvedores de aplicativos
• Se eles não escolheram um mecanismo específico, não levam muito a sério o uso do MySQL e provavelmente não sabem como usá-lo corretamente.
• Você não pode mudar para um mecanismo diferente daquele em que seu aplicativo foi testado, pois pode apresentar erros.

Meu provedor de hospedagem nos aconselhou a nos livrar completamente do MyISAM e mudar para o InnoDB, a menos que isso não seja possível.

No nosso caso, estávamos com uma corrupção de dados grave, que começava a aparecer algumas vezes a algumas vezes por dia, sempre exigindo REPAIR TABLE e comandos relacionados, que levavam anos em tabelas grandes.

Depois que convertemos (ou: fomos convertidos) para o InnoDB, os problemas desapareceram instantaneamente. Desvantagens / advertências que tivemos:

• Não é possível converter tabelas com o índice FULLTEXT (esse problema desapareceu ao longo do tempo por si só; foi substituído por uma solução baseada em Solr / Lucene que, de qualquer maneira, tem uma qualidade muito melhor)
• As grandes tabelas com milhões de linhas que geralmente exigem COUNT (*) eram muito lentas, também não conseguimos alterná-las.

Mas observe: tudo isso é específico ao nosso ambiente, etc., portanto, geralmente não se aplica.