Mecanismo otimizado para pequenas tabelas de pesquisa em MySQL

Question

Eu tenho a seguinte pergunta:Eu sou a concepção de aplicativo da web com várias dezenas de pequenas tabelas de pesquisa:Estas tabelas usualmente conter três colunas (ID, Nome, Descrição) e um par de linhas (a maioria com menos de 50, max é de cerca de 450).

Essas tabelas de pesquisa são esperados para alterar apenas raramente (eles vêm de padrão, que muda de vez em vários anos) e será usada apenas para:

• opções de preenchimento no select do html
• ser associado a outros registros em relatórios

Haverá apenas SELECT declarações sobre essas tabelas 99 % das vezes, mas lá vai ser um monte deles.

Eu estou querendo saber, qual o mecanismo de banco de dados seria mais eficiente utilizar?

Aqui estão as minhas considerações:

MEMÓRIA

• pro:muito rápido
• con:se o servidor falhar, todos os dados são perdidos e precisam ser recriados
• con:não oferece suporte a chaves estrangeiras

comprimido MyISAM

• pro:rápido
• con:não oferece suporte a chaves estrangeiras

O InnoDB

• pro:o suporte a chaves estrangeiras

O que eu gostaria de perguntar, é se haverá uma significativa vantagem em usar algo diferente do que O InnoDB - performance

Obrigado, Zbyněk

Answer 1

Eu respondi a uma pergunta semelhante em agosto de 2011: Qual DBMS é bom para leituras super rápidas e uma simples estrutura de dados?

Como você está perguntando sobre o MySQL e qual motor de armazenamento. Para ser honesto, é difícil dizer porque há raras ocasiões quando Myisam pode superar o InnoDB quando se trata de selecionar.

Aqui estão alguns dos meus posts anteriores nesta controvérsia

• Sep 20, 2011: Melhor de Myisam e InnoDB
• May 03, 2012: Qual é mais rápido, InnoDB ou Myisam? / a>
• Jul 05, 2012: innodb vs myisam com muitos índices
• Sep 26, 2012: Escolhendo Myisam Over InnoDB para esses requisitos de projeto; e opções de longo prazo

Você pode perguntar agora: por que eu sempre favoreceria myisam mais innodb?

Dê uma olhada neste diagrama (criado por Vadim Tkachenko, Perona CTO)

Myisam irá cache indexos e sua tabela terá 2 índices (chave primária no ID e um índice de nome). Por outro lado, o InnoDB tem muitas partes móveis para acomodar, especialmente se a piscina de buffer innodb tiver que carregar e descartar páginas 16K periodicamente.

Para ser justo, você deve fazer um experimento.

• vá para o meu post O que são as principais diferenças entre InnoDB e Myisam? . Leia atentamente.
• Configurar um servidor usando myisam e todas as suas tabelas usando o ROW_FORMAT=Fixed (veja minha postagem Qual é o impacto de desempenho do uso do CHAR vs varchar em um campo de tamanho fixo? ) e use um grande key_buffer_size .
• setup outro servidor usando InnoDB e um grande innodb_buffer_pool_size .
• Adicione seus dados para o servidor e consulte-os como loucos.

Isso lhe dará a melhor avaliação para a opção do motor de armazenamento para o seu conjunto de dados.

experimente !!!

Answer 2

• "Comprimido MyISAM" -- o que é isso?Talvez "Arquivo Morto"?
• A compressão não for necessário;as tabelas são muito pequenos, e rapidamente será totalmente em cache.
• FOREIGN KEYS -- Por quê?Você tem depurado de código, não é?Não haverá oscilação coisas a verificar.
• MEMORY não é razoável, se você escreve 'recarregar' código que é executado sempre que você abrir o servidor, e todas as atualizações para a tabela escritos, tanto para o MEMORY tabela de um persistente de cópia de segurança.
• MyISAM ROW_FORMAT=FIXED -- que é um velho wive do conto;utilização DYNAMIC e VARCHARs.
• O InnoDB é o "cluster" PRIMARY KEY faz pesquisas um pouco mais rápido do que o MyISAM para o seu propósito.
• Você sei que as tabelas de pesquisa estão causando uma notável desaceleração?Eu duvido seriamente que eles são.
• Fazer não usar tabelas de pesquisa para "contínuo" de valores, tais como FLOATs e DATEs.

Eu voto para o InnoDB sem FKs.